Master Thesis Agile Organizations - COREinstitute
Werbung
BIG-DATA-ARCHITEKTURVERGLEICH IM KONTEXT VON VERSICHERUNGEN Corinna, Ludwig September 2016 Bachelor Thesis – Universität Koblenz Landau Copyright © COREtransform GmbH Abstract Insurances deliver a substantial benefit to society through risk transformation. Nevertheless, changes in the competitive and customer environment, and new opportunities through digital developments put pressure on insurance companies. The cornerstone of an insurance’s business (risk management) relies heavily on data analysis. However, growing challenges - due to the rise of information technologies such as Social Media - on the data processing side can no longer be handled by conventional database systems. BigData-architectures can offer solutions for addressing these new challenges and the introduction of a Big-Data capable solution requires the discussion and a structured decision process regarding the architecture of the target. The aim of this bachelor thesis is to provide an overview of the topic Big Data, illuminate the relevance of Big-Data capable solutions for insurance companies and outline a structured decision making process for the design of a Big-Data (based/capable/oriented) architecture. Based on an exemplary evaluation of selected architectures, an outlook for further steps in the decisionmaking process for a target architecture will be presented. The frame of reference for this work is based on the theoretical fundamentals of insurance, software architectures and specific elements of the Big-Data ecosystem derived from literature review. The relevance of Big-Data is analyzed with the “cartesian coordinate diagram” research tool. Based on the theoretical requirements for Big-Data systems a taxonomy for the comparison of selected architectures is established. The evaluation of architectures is implemented by using an adapted scoring model. Real-life testing of the taxonomy is still pending. While the present analysis is based on equally weighted requirements, further criteria of different natures have to be considered in real-life. The validation along the entity's specific circumstances in the practical selection of an architecture has to be conducted. Based on a successful implementation of a Big-Data architecture, the foundation for advanced applications, such as artificial intelligence, is being set. Future requirements regarding the increasing internetworking of physical devices - "Internet of Things" - is taken into account. Therefore insurance companies can continue fulfilling their role in society and simultaneously raise new business opportunities. New technologies such as artificial intelligence can be established for the insurance industry for the first time. II Bachelor Thesis Corinna Ludwig © CORE 2016 Zusammenfassung Versicherungsinstitute bieten mit der Risikotransformation einen positiven Nutzen für die Gesellschaft. Die aktuelle Veränderungen der Wettbewerbs- und Kundensituation, sowie die neuen Chancen durch digitale Initiativen üben jedoch für die Assekuranz einen Handlungsdruck aus. Im Fokus dieser Arbeit steht mit der unternehmerischen Datenbewirtschaftung der Eckpfeiler ihrer Wertschöpfung. Wachsende Herausforderungen an die Datenverarbeitung können durch herkömmliche Datenbanksysteme nicht mehr abgebildet werden. Lösungsansätze werden durch die Technologische Innovation Big-Data möglich. Die Entscheidungsgrundlage bezüglich möglicher Architekturen bei der Einführung von Big-Data-Lösung bei Versicherungsinstituten ist objektiviert nicht verfügbar. Ziel der Bachelorarbeit ist es, einen Überblick über das Thema Big-Data zu geben. Neben der Relevanz-Analyse von Big-Data-Lösungen für Versicherungen soll die Entscheidungsfindung für eine Big-Data-Architektur objektivierbar gestaltet werden. Auf Basis einer beispielhaften Bewertung ausgewählter Architekturen soll ein Ausblick auf weitere Schritte des Entscheidungsprozess für eine Zielarchitektur formuliert werden. Der Bezugsrahmen der Arbeit wird von theoretischen Grundlagen zu Versicherungen, SoftwareArchitekturen und spezifischen Elementen von Big-Data-Technologien auf Basis einer Literaturrecherche hergestellt. Zur Objektivierung der Relevanz von Big-Data soll ein kartesisches Koordinatendiagramm als Analyseinstrument herangezogen werden. Basierend auf theoriebasiert entwickelten Anforderungen an ein Big-Data-System wird eine Taxonomie für den Vergleich ausgewählter Architekturen abgeleitet. Die Bewertung der Architekturen erfolgt mittels eines adaptierten Scoring-Modells. Eine Praxiserprobung der vorgeschlagenen Taxonomie steht bislang noch aus. Während für die vorliegende Analyse gleichgewichtete Anforderungen an die Architektur angenommen wurden, wären in der praktischen Auswahl einer Architektur die unterschiedliche Natur der Kriterien individuell erneut zu betrachten und eine Validierung entlang der unternehmensspezifischen Gegebenheiten vorzunehmen. Auf Basis einer erfolgreich implementierten Big-Data-Architektur können Versicherungsinstitute bereit gemacht werden für zukünftige Anforderungen aus der zunehmenden Vernetzung von Geräten und Maschinen - „Internet der Dinge“. So können sie ihre risikosenkende Rolle für die Gesellschaft weiterhin wahrnehmen und gleichzeitig neue Geschäftspotentiale heben. Fortschrittlichste Anwendungen wie künstliche Intelligenz werden technologisch erstmalig für diese Branche ermöglicht. III Bachelor Thesis Corinna Ludwig © CORE 2016 Inhaltsverzeichnis Abstract ....................................................................................................................................... II Zusammenfassung ..................................................................................................................... III Inhaltsverzeichnis ....................................................................................................................... IV 1 Einleitung ................................................................................................................................ 8 1.1 Problemstellung .............................................................................................................. 8 1.2 Ziel der Untersuchung .................................................................................................. 11 1.3 Beschreibung der Methoden......................................................................................... 12 1.4 Aufbau der Arbeit.......................................................................................................... 12 2 Theoretische Grundlagen: Versicherungen ........................................................................... 14 2.1 Das Versicherungsunternehmen .................................................................................. 14 2.1.1 Aufgaben und Organisation ............................................................................ 14 2.1.2 Datenverarbeitung / IT .................................................................................... 15 2.2 Wettbewerb und Kunden .............................................................................................. 16 2.2.1 Wettbewerbsumfeld ........................................................................................ 16 2.2.2 Kundenumfeld ................................................................................................. 18 3 Theoretische Grundlagen: Technologien .............................................................................. 21 3.1 Software-Architekturen ................................................................................................. 21 3.1.1 Der Software-Architektur-Lebenszyklus .......................................................... 22 3.1.2 Das Konzept einer Architekturbeschreibung ................................................... 22 3.1.3 Qualitätsanforderungen an eine Software-Architektur .................................... 24 3.2 Big-Data-Technologien ................................................................................................. 27 3.2.1 Verschiedene Definitionen zu Big-Data .......................................................... 28 3.2.2 Bekannteste Definition von Big-Data: Das 3-V-Modell .................................... 29 3.2.3 Einführung in No-SQL Datenmodelle .............................................................. 30 3.2.4 Das Big-Data-Ökosystem: Das 5-V-Modell ..................................................... 33 3.2.5 Big-Data-Engineering...................................................................................... 34 3.2.6 Datenlebenszyklus .......................................................................................... 34 3.2.7 Schichten und Bausteine einer Big-Data-Lösung ........................................... 35 3.2.8 Big-Data-Referenzarchitekturen ..................................................................... 36 4 Analyseinstrumente............................................................................................................... 41 4.1 Das Kartesische Koordinatensystem ............................................................................ 41 4.2 Das Scoring-Modell ...................................................................................................... 42 5 Big-Data-Architekturen im Kontext Versicherungen .............................................................. 43 5.1 Relevanz von Big-Data bei Versicherungen ................................................................. 43 5.1.1 Chancen und Herausforderungen der Einführung einer Big-Data-Lösung einführen ............................................................................................. 45 5.1.2 Chancen und Herausforderungen bei der Weiterarbeit ohne eine Big-DataLösung................................................................................................. 46 5.1.3 Erkenntnisse und Folgerungen ....................................................................... 47 5.2 Big-Data-Architekturentscheidung ................................................................................ 48 5.2.1 Klassifikation und Herleitung der Kriterien für die Taxonomie ......................... 48 IV Bachelor Thesis Corinna Ludwig © CORE 2016 5.2.2 5.2.3 5.2.4 5.2.5 Anwendung der Taxonomie am Beispiel des Vergleichs von Lambda- und Kappa-Architektur ................................................................................ 60 Konkretisierung des Scoring-Modells und Ausgestaltung ............................... 66 Anwendung der Bewertungsmethode am Beispiel des Vergleichs von Lambda- und Kappa-Architektur .......................................................... 67 Erkenntnisse und Folgerungen ....................................................................... 68 6 Schluss ................................................................................................................................. 72 6.1 Zusammenfassung ....................................................................................................... 72 6.2 Ausblick ........................................................................................................................ 74 Autorin ...................................................................................................................................... 78 Über das COREinstitute .......................................................................................................... 79 V Bachelor Thesis Corinna Ludwig © CORE 2016 I Abbildungsverzeichnis ABBILDUNG 1: W ERTSCHÖPFUNGSKETTE EINER VERSICHERUNG 15 ABBILDUNG 2: SOFTWARE-ARCHITEKTUR-LEBENSZYKLUS 22 ABBILDUNG 3: DIMENSIONEN VON BIG-DATA: DAS 3-V-MODELL 30 ABBILDUNG 4: SCHICHTEN UND BAUSTEINE EINER BIG-DATA-LÖSUNG 36 ABBILDUNG 5: LAMBDA-ARCHITEKTUR 39 ABBILDUNG 6: BIG-DATA URSACHE-W IRKUNG-MATRIX 45 II Tabellenverzeichnis TABELLE 1: QUALITÄTSKRITERIEN SOFTWARE-ARCHITEKTUR (QUELLE: EIGENE DARSTELLUNG) 26 TABELLE 2: CHANCEN DURCH DEN EINSATZ VON BIG-DATA (QUELLE: BITKOM 2012, 5) 28 TABELLE 3: KRITERIUM KURZBESCHREIBUNG (EIGENE DARSTELLUNG) 49 TABELLE 4: KRITERIUM HAUPTZIEL (EIGENE DARSTELLUNG) 49 TABELLE 5: KRITERIUM ANNAHMEN (EIGENE DARSTELLUNG) 50 TABELLE 6: KRITERIUM PARADIGMEN (EIGENE DARSTELLUNG) 51 TABELLE 7: SUBKRITERIUM PARADIGMEN 55 TABELLE 8: KRITERIUM ANFORDERUNGEN (EIGENE DARSTELLUNG) 56 TABELLE 9: SUBKRITERIUM ANFORDERUNGEN (EIGENE DARSTELLUNG) 58 TABELLE 10: KRITERIUM RISIKEN 58 TABELLE 11: KRITERIUM REIFEGRAD 59 TABELLE 12: KRITERIUM REFERENZEN (EIGENE DARSTELLUNG) 59 TABELLE 13: TAXONOMIE (EIGENE DARSTELLUNG) 60 TABELLE 14: VERGLEICH VON LAMBDA- UND KAPPA-ARCHITEKTUR (EIGENE DARSTELLUNG) 66 TABELLE 15: BEWERTUNGSSKALA (EIGENE DARSTELLUNG) 67 TABELLE 16: SCORING-MODELL (EIGENE DARSTELLUNG) 68 VI Bachelor Thesis Corinna Ludwig © CORE 2016 III Abkürzungsverzeichnis ATAM Architecture tradeoff analysis method B2B Business-to-business BaFin Bundesanstalt für Finanzdienstleistungsaufsicht BI Business Intelligence BITKOM.Bundesverband Informationswirtschaft, Telekommunikation und neue Medien CAP C consistency, A availability, P partition tolerance CEP Complex Event Processing COCOMO Constructive Cost Model CPU CRM Customer Relationship Management ELT Extract, Load, Transform engl englisch ERP Enterprise Ressource Planning ETL Extract, Transform, Load FinTech Financial Services Technologies GDV Gesamtverband der Deutschen Versicherungswirtschaft e.V. GPS Global Positioning System IBM International Business Machines Corporation IDC International Data Corporation IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IFIP International Federation for Information Processing InsurTech Insurance Technologies ISO International Organization for Standardization IT Informationstechnologie JMS Java Message Service JSBM Journal of Small Business Management KFZ Kraftfahrzeug M2M Machine-to-Machine NASA National Aeronautics and Space Administration NoSQL Not only SQL OLAP Online Analytical Processing OLTP Online Transaction Processing RAM Random Access Memory ROPO Research Online, Purchase Offline SQL Structured Query Language STEP Social, Technological, Economic, Political U.S United States (of America) UML Unified Modelling Language VAG Versicherungsaufsichtsgesetz WICSA Working IEEE/IFIP Conference on Software Architecture XML Extensible Markup Languag Central Processing Unit VII Bachelor Thesis Corinna Ludwig © CORE 2016 73 1 Einleitung 1.1 Problemstellung „Paukenschlag bei der Ergo Versicherung: Gestern verkündete Vorstandschef Markus Rieß ein hartes Sanierungsprogamm, dem über 1.800 Arbeitsplätze zum Opfer fallen sollen. Rund 450 Millionen Euro jährlich wollen die Düsseldorfer bis 2020 einsparen. Gleichzeitig sind Investitionen von einer Milliarde Euro geplant. Wir werden uns kompromisslos am Kunden orientieren. Dafür müssen wir schlanker, effizienter und digital werden", sagte Rieß auf einer Pressekonferenz“ (Versicherungsmagazin 2016, 1). und auch der Marktführer in Deutschland Allianz stellte sein Umbauprogramm 2014 vor „Die Zahl der Allianz-Kunden, die alles ganz traditionell über einen Vertreter regeln lassen, sinkt schnell: von rund 90 Prozent 2005 auf weniger als 50 Prozent heute. Mit einem 80 Millionen Euro schweren Programm versucht die Führung der Allianz Deutschland deshalb nun, das 124 Jahre alte Traditionsunternehmen fit zu machen für die digitale Ära“ (Süddeutsche.de GmbH, Munich & Germany 2014). Die Ursprünge von Versicherungen gehen bis 400 v.Chr. zurück (Museum der deutschen Versicherungswirtschaft 2007). Eine der frühen Formen der Versicherungen war die Absicherung des Risikos im Seehandel. Versicherungen sind somit eine seit hunderten Jahren bekannte Mitigationsmaßnahme gegenüber möglicherweise existenzvernichtenden Risiken und sowohl im privaten als auch im geschäftlichen Umfeld von eminenter Bedeutung. (Prognos 2013) Seit dem 17. Jahrhundert nutzt die Versicherungswirtschaft mathematische Methoden zur Einschätzung von Risiken. Die Datenverarbeitung dient als Grundpfeiler analog dem Gesetz der großen Zahl für die Quantifizierung solcher Risiken. (GDV 2015a) Die Bedeutung des Versicherungsunternehmens manifestiert sich unter anderem durch die Einordnung als sogenannte kritische Infrastruktur des Bundesministeriums des Innern. Sektoren zählen dann zur kritischen Infrastruktur sobald deren Ausfall oder Beeinträchtigung einen nachhaltigen Versorgungsmangel oder Beeinträchtigung der öffentlichen Sicherheit zur Folge hat. Neben Banken und Versicherungen werden unter anderem Energie, Wasser und Gesundheit als kritische Infrastruktur geführt. (Prognos 2013) Die volkswirtschaftliche Bedeutung der Finanz- und Versicherungsdienstleistungen zeigt sich in dem hohen Anteil von 4,5 Prozent am Bruttoinlandsprodukt. Somit liegt die Finanzindustrie noch vor den Branchen Fahrzeugbau, Maschinenbau und Energieversorgung im Jahr 2010 (Statistisches Bundesamt 2010). Erkennbar ist diese Bedeutung nicht zuletzt auch in rechtlich vorgeschriebenen Versicherungsformen wie Kranken- oder Haftpflichtversicherungen (Prognos 2013). Weitere Versicherungen wie Berufsunfähigkeits-, Rechtsschutz- oder Hausratsversicherungen sind von herausgehobener Wichtigkeit. Schätzungen zufolge besitzen beispielsweise 51Prozent deutscher Haushalte eine Hausratsversicherung (IfD Allensbach 2015). Es ist Bewegung in den Versicherungsmarkt gekommen (Zimmermann G. 2015, 91). Die Bedeutung dieser Bewegung zeigt sich unter anderem in den erwähnten Programmen der ausgewähl- 8 Bachelor Thesis Corinna Ludwig © CORE 2016 73 ten Zitate: Stellen werden abgebaut, kundenorientiertes Denken und Digitalisierung werden gefordert (Versicherungsmagazin 2016; Süddeutsche.de GmbH, Munich & Germany 2014). Die Gründe sind vielschichtig: der Eintritt neuer Wettbewerber und technologische Entwicklungen sowie die Veränderungen der Kundenbedürfnisse konnten als maßgebliche Einflussfaktoren für die anfangs beschriebenen Bewegungen im Versicherungsmarkt identifiziert werden (Zimmermann G. 2015, 91). Ein erster Grund für den erhöhten Druck auf Versicherungsunternehmen ist der Eintritt neuer Marktteilnehmer und branchenfremder Akteure unter Nutzung der technologischen Entwicklung. InsurTechs haben sich als neue Spieler am Markt etabliert (Altuntas P. & Uhl P. 2016). Der Begriff InsurTechs setzt sich aus Insurance und Technology zusammen und markiert den Eckpfeiler für die Veränderung der Versicherungsbranche durch die Nutzung neuer Technologien sowie die Etablierung alternativer digitaler Geschäftsmodelle (GruenderSzene 2016a). InsurTechs platzieren sich entlang der Wertschöpfungskette des Versicherungsunternehmens und führen zu einer Fragmentierung der Wertschöpfung (deutsche-startups.de 2016). Nach Angaben von CORE Consulting gibt es mittlerweile 57 InsurTech Start-Ups in Deutschland (COREtechmonitor 2016), zehn InsurTech Start-Ups werden durch Venture Kapital unterstützt, über 40 Millionen Euro Venture Kapital wurde seit 2012 investiert (Barkow Consulting 2016). Das Online-Magazin GruenderSzene beschreibt die Revolution der Versicherungsbranche durch Start-Ups: Start-Ups nutzen Technologien wie Big-Data kundenorientiert, werden finanziell gefördert und entscheiden so über die Entwicklung der Branche (GruenderSzene 2016b). Es besteht außerdem das Risiko, dass branchenfremde Akteure mit datengetriebenen Geschäftsmodellen und einem guten Kundenzugang wie Google oder Amazon in den Markt eintreten könnten (Versicherungsbote 2014). Derzeit ist das Kerngeschäft eines Versicherungsunternehmens weitestgehend unberührt geblieben. Das Risiko der weiteren Fragmentierung der Wertschöpfungskette und Eintritt branchenfremder Akteure bleibt bestehen. Kundenzufriedenheit ist einer der Erfolgshebel für nachhaltigen Geschäftserfolg. Zufriedenere Kunden sind loyaler und sind eher dazu bereit, Produkte und Dienstleistungen weiterzuempfehlen und diese auch zukünftig zu nutzen. Nach Oletzky führt eine gesteigerte Kundenzufriedenheit zu einer höheren Kundenbindung und wirkt sich positiv auf die Neuakquise aus (Oletzky T., Staud N & Boltz J., 257). Kundenzufriedenheit kann nur dann gesteigert werden, wenn das Kundenverhalten bekannt ist. Die derzeit maßgebenden Trends des Kundenverhaltens konnten identifiziert werden: Eine erhöhte Nutzung von Vergleichsportalen und Internetseiten der Versicherungsanbieter als Informationsquelle, ein erhöhtes Kostenbewusstsein und die Bequemlichkeit eines Vertragsabschlusses als Entscheidungskriterium für die Auswahl eines Anbieters (Gerlach V. & Gruber M. 2012, 67). Laut den Versicherungsforen Leipzig ist „der Kunde von heute immer vernetzt, stets informiert und anspruchsvoll“ (Wedekind K., Dormann B. & Lay U. 2016, 5). Markus Rosenbaum erklärte auf der Konferenz Digisurance im Jahr 2016, dass die größte Ineffizienz in der Versicherungsbranche die Kundenschnittstelle sei (Wedekind K., Dormann B. & Lay U. 2016, 5). Hier müssen sich traditionelle Versicherungen bei der Erfüllung der Kundenerwartungen an anderen Branchen messen, schneiden im Vergleich jedoch nicht gut ab (Zimmermann G. 2015, 91). Das Image der Versicherungswirtschaft ist nach Oletzky schlecht. Medienberichten zu Folge ist 9 Bachelor Thesis Corinna Ludwig © CORE 2016 73 der Hauptgrund hierfür Intransparenz und mangelnde Verständlichkeit von Versicherungsunterlagen (Oletzky T., Staud N & Boltz J.). Versicherungen werden mit den Herausforderungen veränderten Kundenverhaltens und Kundenerwartungen einer digitalen Generation konfrontiert (Altuntas P. & Uhl P. 2016, 23-29). Auch die Veränderungen im Kundenumfeld sowie im Wettbewerbsumfeld, werden von technologischen Entwicklungen getrieben. Im Zuge dessen ist der Begriff Digitalisierung zu nennen. Der Begriff Digitalisierung hat verschiedene Bedeutungen. Eine wesentliche Definition beschreibt die digitale Transformation als „fundamentalen Wandel von Unternehmen hin zu einer vollständig vernetzten digitalen Organisation. Auf Basis von neuen Technologien und Applikationen werden Prozesse (…) umgestaltet und an die Anforderungen (Echtzeit, Vernetzung) der digitalen Ökonomie angepasst“ (Büst R., Hille M. & Schestakow S. 2015, 6). Verschiedene technologische Entwicklungen im Rahmen des digitalen Wandels, das Internet der Dinge, Big-Data, Social Media, Künstliche Intelligenz und Cloudtechnologien, eröffnen Chancen für Veränderungen von Geschäftsmodellen, Wertschöpfungsketten sowie der Kundeninteraktion (Binckebanck L. & Elste R. 2016, 266-268). Big-Data ist ein wesentlicher Aspekt der technologischen Entwicklung und soll hier hervorgehoben werden. Die Definitionen für Big-Data sind allerdings nicht einheitlich. Die bekannteste Definition von Gartner beschreibt Big-Data als einen Informationsbestand, der anhand von drei Dimensionen klassifiziert werden kann: ansteigendes Volumen der Daten (engl. volume), ansteigende Geschwindigkeit der Datenverarbeitung (engl. velocity) und eine erhöhte Datenvielfalt (engl. variety) (Demchenko, Laat & Membrey, 2). Wie bereits erwähnt ist die Datenverarbeitung maßgebend für die Risikoeinschätzung im Versicherungsunternehmen. In einer Studie von BITKOM (2014) verzeichneten neun von zehn Unternehmen ein durchschnittliches Datenvolumenwachstum um 22 Prozent (Weber M., Dehmel S. & Hampe K. 2014, 15). Zusätzlich zu dem Anstieg des Datenvolumens erhöhte sich der Anteil an unstrukturierten Daten aus Informationstechnologien wie Social Media und Real Time, Mobile Apps, Location-Based Services, Cloud Computing und Sensorik und Machine-To-Machine (M2M) (Weber M., Dehmel S. & Hampe K. 2014, 8). Die wachsenden Herausforderungen an die Datenverarbeitung können durch herkömmliche Datenbanksysteme nicht mehr abgebildet werden (Versicherungsforen Leipzig 2014). Unstrukturierte Daten sind ohne Big-Data nicht als Entscheidungsgrundlage verwertbar. Durch Big-Data wird die Analyse und Verarbeitung von Informationen in großen Mengen und hoher Geschwindigkeit möglich. Die Erkenntnisse aus der Verwertung bislang unzugänglicher Daten ermöglichen zeitnahe Entscheidungsgrundlagen und bieten so die Chance, sich auf Marktanforderungen besser einzustellen und die Wettbewerbsfähigkeit zu steigern (Weber M., Dehmel S. & Hampe K. 2014, 8). Des Weiteren bietet eine bessere Datengrundlage die Möglichkeit, im Vertrieb Kunden über eine 360-Grad-Sicht analysieren zu können. Im Bereich Produktentwicklung könnten KFZVersicherungen beispielsweise individuell auf der Basis von Sensorikdaten bemessen werden oder künstliche Intelligenz bei der Ermittlung von Risiken und Schadensquoten eingesetzt werden. Big-Data bietet die Chance, neue Quellen für Wertschöpfung auszuschöpfen, Aktion als 10 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Paradigma anstatt Reaktion auf Marktveränderungen zu etablieren und eine angemessenere Entscheidungsbasis sowie Kundenkenntnis zu bieten. Die Veränderungen der Wettbewerbs- und Kundensituation sowie die neuen Chancen durch digitale Initiativen verdeutlichen den Handlungsdruck für Versicherungen (Nicoletti B. 2016, 2). BigData kann eine mögliche Lösung sein, um Chancen für traditionelle Versicherungsunternehmen zu schöpfen. Da die Einführung einer Big-Data-Lösung eine Vielzahl an Implikationen für das Unternehmen bereithält, muss der Entscheidungsprozess für eine neue Architektur von den relevanten Stakeholdern objektiviert werden. Herausforderungen im Kunden- und Wettbewerbsumfeld sowie die technologischen Entwicklungen sind bereits Gegenstand der wissenschaftlichen Literatur. Big-Data-Technologien und deren Anwendungsszenarien sowie Nutzungspotenziale werden thematisiert. Es besteht jedoch eine Forschungslücke in der gesamtheitlichen Betrachtung des Big-Data-Ökosystem und in der Herleitung der Relevanz für Versicherungen in der Literatur. Des Weiteren gibt es bereits Forschungsstände zu Bewertungsmethoden von Software-Architekturen im Fall von bereits konkret getroffenen Systementscheidungen. Die in den Lehrbüchern beschriebenen Methoden bewerten konkrete Systementscheidungen, aber keine Architekturansätze, die als Vorlage für die weitere Konzeption und Entwurf einer Anwendung dienen. Der Big-Data-Architekturansatz - die LamdbaArchitektur - wird in der Literatur beschrieben. Weitere Architekturansätze wie die Kappa-Architektur werden auf Blogs und in Videos thematisiert. Diese werden jedoch in der Literatur weder verglichen noch bewertet. An den Forschungslücken - die fehlende ganzheitliche Betrachtung des Big-Data-Ökosystems, die Herleitung der Relevanz für Versicherungen, die Nichtexistenz von Architekturevaluationsmethoden für Architekturansätze und der fehlende Vergleich sowie Bewertung von bestehenden BigData-Architekturansätzen - soll in dieser Arbeit angesetzt werden. 1.2 Ziel der Untersuchung Ziel der Bachelorarbeit ist es, einen Überblick über das Thema Big-Data zu geben, die Relevanz von Big-Data-Lösungen für Versicherungen aufzuzeigen, die Entscheidungsfindung für eine BigData-Architektur zu objektivieren, erste Ergebnisse aus einem Vergleich und der Bewertung ausgewählter Architekturen abzuleiten und einen Ausblick auf weitere vorzunehmende Schritte entlang des Entscheidungsprozess für eine Zielarchitektur zu geben. Im Zuge dieser Arbeit soll auf folgende Forschungsfragen eine Antwort gefunden werden: F1: Ist der Einsatz von Big-Data für ein Versicherungsunternehmen von Relevanz? F2: Wie könnte ein Modell zur Objektivierung der Architekturentscheidung für Big-DataLösungen aussehen? F3: Welche Ergebnisse liefern der Vergleich und die Bewertung ausgewählter Architekturen mit Hilfe des Modells? 11 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Im Ausblick wird erläutert, welche weiteren Schritte unternommen werden könnten, um die Taxonomie zu validieren und die Entscheidung für eine Architektur zu objektivieren. 1.3 Beschreibung der Methoden Die Basis der Bachelorarbeit bildet eine Literaturanalyse zu den folgenden Themen: Versicherungen, Herausforderungen im Kunden- und Wettbewerbsumfeld bei Versicherungen, Grundlagen zur Software-Architektur, das Big-Data-Ökosystem, Analyseinstrumente zur Bewertung von Optionen und Strukturierung von Entscheidungen. Die strategische Einordnung erfolgt durch eine Teilbetrachtung der Umfeldanalyse gemäß des STEP Modells (technologische Betrachtung) und Porters Five-Forces-Modell (Betrachtung des Wettbewerbs- und Kundenumfeld). Der Fokus liegt hier auf der Herleitung des Big-Data-Ökosystems. So können die abstrakten Zusammenhänge in der wissenschaftlichen Theorie offengelegt werden und dienen somit als qualitative Grundlage für die Herleitung einer Taxonomie. Die Literatur hierzu ist weitestgehend englischsprachig. Zur Objektivierung der Relevanz von Big-Data soll als Analyseinstrument ein kartesisches Koordinatendiagramm herangezogen werden. Hier werden die erlangten Kenntnisse über Herausforderungen im Kunden-, Wettbewerbsumfeld und durch technologische Veränderungen aufbereitet. Basierend auf den in der Theorie ersichtlichen Anforderungen an ein Big-Data-System wird eine Taxonomie für den Vergleich ausgewählter Architekturen abgeleitet. Die Taxonomie beschreibt ein Modell nach dem die Architekturen klassifiziert werden. Hierzu werden Kriterien aus der Theorie hergeleitet, Obergruppen gebildet und Subkriterien definiert. Diese Kriterien sind indikativer und objektiver Natur. Diese werden benannt und beschrieben. Die Bewertung der Architekturen erfolgt auf Basis der Methodik von Scoring-Modellen. In der quantitativen Analyse wird das Kriterium „Anforderungen“ herangezogen. Die konkrete Anwendung der Methodik in diesem Anwendungsfall wird hergeleitet. Der tatsächliche Vergleich und die Bewertung der Architekturen werden tabellarisch visualisiert. 1.4 Aufbau der Arbeit Zur Beantwortung der Forschungsfragen gliedert sich die folgende Arbeit in fünf Kapitel. Im Kapitel eins wird nach der Einordnung der Thematik und Formulierung einer Problemstellung. Diese manifestiert sich sowohl im gesamtwirtschaftlichen Zusammenhang als auch in den großen Linien 12 Bachelor Thesis Corinna Ludwig © CORE 2016 73 der Versicherungsbranche. Darüber hinaus wird die wissenschaftliche Herangehensweise dargelegt. Die Kapitel zwei und drei legen theoretische Grundlagen für die darauf folgende praxisbezogene Betrachtung. Das Kapitel zwei fokussiert dabei die Assekuranz; zum einen werden die Versicherungsunternehmen selbst in den Fokus genommen, zum anderen ihr ökonomisches Umfeld. Das folgende Kapitel drei erörtert wesentliche Konzepte zum Verständnis von Software-Architekturen und ihrer Eigenschaften. Weiterhin werden verschiedene Definitionen von Big-Data diskutiert und erste Erkenntnisse in Bezug auf Datenmodelle formuliert. Zuletzt werden Schichten und Bausteine einer Big-Data Lösung vorgestellt und bekannte Referenzarchitekturen skizziert sowie zur folgenden Analyse ausgewählt. Im Kapitel vier werden Analyseinstrumente für Big-Data-Lösungen entwickelt. Darauf aufbauend wird im Kapitel fünf die Relevanz von Big-Data für Versicherungen erörtert. Ein Modell für den Vergleich und die Bewertung wird hergeleitet. Unter Anwendung auf die im Kapitel drei ausgewählten Referenzarchitekturen wird das Modell erprobt, um Erkenntnisse und Folgerungen ableiten zu können. Diese Erkenntnisse beziehen sich auf Entscheidungsprozesse zur Auswahl und Einführung einer Big-Data-Lösung. Im Kapitel sechs werden die Erkenntnisse zusammengefasst und die Grenzen des Modells betrachtet sowie ein Ausblick für ihre Anwendung in der Praxis gegeben. 13 Bachelor Thesis Corinna Ludwig © CORE 2016 73 2 Theoretische Grundlagen: Versicherungen Das folgende Kapitel strukturiert sich wie folgt: Einführung in die Aufgaben, Organisation und die Funktion der IT im Versicherungsunternehmen, Einführung in die Herausforderungen im Wettbewerbsumfeld und Kundenumfeld. Die Beschreibung der theoretischen Grundlagen zum Thema Versicherungen ist notwendig, um Ansatzpunkte für die Relevanz von Big-Data identifizieren zu können. 2.1 Das Versicherungsunternehmen In diesem Kapitel werden die Aufgaben und die Organisation, die Wertschöpfungskette sowie die Datenverarbeitung/IT als Eckpfeiler für die Absicherung von Risiken im Versicherungsunternehmen skizziert. Die Beschreibung dient dazu, Datenverarbeitung als Fundament für ein Versicherungsunternehmen zu manifestieren und so zusammen mit den anderen Bereichen der Wertschöpfungskette einen ersten Ansatzpunkt für die Relevanz von Big-Data zu identifizieren. 2.1.1 Aufgaben und Organisation An dieser Stelle soll das Versicherungsunternehmen definiert, die Hauptaufgabe eines Versicherungsunternehmens, der Grundsatz der Spartentrennung und die Wertschöpfungskette erläutert werden. Die Ursprünge von Versicherungen gehen - wie in der Einleitung beschrieben - bis 400 v.Chr. zurück (Museum der deutschen Versicherungswirtschaft 2007). Versicherungen sind eine seit hunderten Jahren bekannte Mitigationsmaßnahme gegenüber möglicherweise existenzvernichtenden Risiken und sowohl im privaten als auch im geschäftlichen Umfeld von eminenter Bedeutung (Prognos 2013). Im Gabler-Lexikon Versicherung wird das Versicherungsunternehmen wie folgt beschrieben: Definition: „Neben dem Versicherungsnehmer die zweite Vertragspartei in einem Versicherungsvertrag. Das Versicherungsunternehmen ist der Verkäufer von Versicherungsschutz. Das Versicherungsunternehmen übernimmt gegen eine kalkulierte Prämie das versicherte Risiko von einem Versicherungsnehmer und ist bei Eintritt des Versicherungsfalls verpflichtet, die vereinbarte Versicherungsleistung zu erbringen“ (Wagner 2011, 731). Die Hauptaufgabe des Versicherungsunternehmens liegt in der Risikotransformation. Die wirtschaftliche Grundlage hierfür bildet das Gesetz der großen Zahl. Hier ist die Übernahme einer Reihe gleichartiger, jedoch voneinander unabhängiger Risiken der Grundbaustein für den Risikoausgleich eines Unternehmens. (Mayer 1999, 2) Auf Grund der Absicherung von Risiken nehmen Versicherer wie Banken eine zentrale volkswirtschaftliche Rolle ein und unterliegen staatlicher Kontrolle (Versicherungsaufsichtsgesetz - VAG). Die zuständige Aufsichtsbehörde ist die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), das zuständige Fachministerium ist das Bundesministerium der Finanzen. Eine Versicherung in 14 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Deutschland kann als Rechtsform ein Verein, eine Aktiengesellschaft, eine Anstalt oder eine Körperschaft des öffentlichen Rechts sein. Versicherungen werden nach dem versicherten Risiko in Sparten eingeteilt; dies sind traditionell die Sachversicherungen, Krankenversicherungen, Lebensversicherungen und Rückversicherungen. Es gilt der Grundsatz der Spartentrennung: Für die Sparten Lebensversicherung und Krankenversicherungen müssen getrennt von den übrigen Versicherungssparten eigene Rechtseinheiten gebildet werden. (Altuntas P. & Uhl P. 2016, 9) Die Wertschöpfungskette erstreckt sich wie in der Abbildung 1 dargestellt von Rückversicherung im Bereich Beschaffung, Produktentwicklung, Underwriting, Risikotragung und Risikotransformation, Asset-Management und Marketing im Bereich Produktion sowie Vertrieb im Bereich Absatz. Übergreifende Aktivitäten sind Bestandsverwaltung, Datenverarbeitung/IT, Unternehmensführung, Finanzen und Controlling sowie Personal. (Altuntas P. & Uhl P. 2016, 81). Festzuhalten ist, die Hauptaufgabe der Versicherung liegt in der Risikotransformation. VersicheAbbildung 1: Wertschöpfungskette einer Versicherung (Quelle: eigene Darstellung in Anlehnung an Altuntas P. & Uhl P. 2016, 81) rungen unterliegen staatlicher Kontrolle, werden nach den versicherten Risiken in Sparten unterteilt und die Wertschöpfung erstreckt sich weiterhin auf die Bereiche Marketing und Vertrieb, Asset- und Schadenmanagement, Underwriting und Produktentwicklung. 2.1.2 Datenverarbeitung / IT An dieser Stelle soll die Wichtigkeit der Datenverarbeitung für ein Versicherungsunternehmen, um Risiken abschätzen zu können sowie die neuen Herausforderungen durch erhöhte Datenmengen für die IT in Versicherungen kurz skizziert werden. Seit dem 17. Jahrhundert nutzt die Versicherungswirtschaft mathematische Methoden zur Einschätzung der Risiken. Statistische Modelle und die technischen Möglichkeiten der Datenerhebung haben sich seither weiterentwickelt. Seit 2007 sind 94 Prozent aller Daten weltweit digital anstatt analog in Akten oder Büchern abgespeichert. Versicherungen profitieren von den Entwicklungen in der Mathematik und Datenverarbeitung (GDV 2015a). Das Geschäftsmodell be- 15 Bachelor Thesis Corinna Ludwig © CORE 2016 73 steht aus der Absicherung von Risiken und ist daher datengetrieben. Das Instrument für die Abschätzung des Eintritts eines Ereignisses ist die Wahrscheinlichkeitsrechnung. Die Basis ist wie beschrieben das Gesetz der großen Zahl von Bernoulli, welches besagt, dass der Eintritt eines Ereignisses umso genauer bestimmt werden kann, desto größer die Stichprobe ist. Je mehr quantifizierbare Daten vorliegen, desto genauer kann ein Versicherungsunternehmen Risiken bestimmen. Aus diesem Grund sammeln Versicherungsunternehmen seit ihrer Existenz Daten. Die Anforderungen an Speicherung und Verarbeitung der Informationen stiegen mit dem Umfang und Varietät an Daten (GDV 2015c). Da die Datenverarbeitung die Grundlage für die Einschätzung von Risiken bildet, trägt die IT in Versicherungen als Grundpfeiler der Wertschöpfungskette eminent zum Unternehmenserfolg bei. Als Querschnittsfunktion unterstützt die IT die Unternehmenssparten beim Heben von Innovationspotenzialen, beispielsweise der Etablierung von digitalen Vertriebskanälen für den Kunden. Die Datenverarbeitung steht vor neuen Herausforderungen. Nach Aussagen von BITKOM verzeichneten Unternehmen einen Anstieg von Datenvolumen um circa 22 Prozent. Rund 85 Prozent liegen in einem unstrukturierten Format vor und sind von einem herkömmlichen Datenbanksystem nicht verwertbar (Weber M., Dehmel S. & Hampe K. 2014, 5). Laut den Versicherungsforen Leipzig gibt es Indizien dafür, dass herkömmliche Datenbanksysteme in Versicherungsunternehmen nicht in der Lage sind die beschriebenen großen Datenmengen in der gewünschten Zeit sowie die neuen Datenformate zu verarbeiten. Trotz der Bedeutung der IT für Versicherungen wären die IT-Systeme oft veraltet und schwerfällig. Die IT-Budgets seien knapp und der Integrationsaufwand neuer Lösungen in die alte Systemlandschaft wäre hoch (Versicherungsforen Leipzig 2014). Im Ergebnis bildet die Datenverarbeitung die Grundlage für die Einschätzung von Risiken bei Versicherungen. Die Verarbeitung von größeren Datenmengen dient analog dem Gesetz der großen Zahl einer genaueren Bestimmung von Risiken. Der Anstieg von Datenvolumen sowie unstrukturierten Daten kann jedoch durch herkömmliche Datenbanksysteme nicht mehr in ausreichender Geschwindigkeit und Qualität sichergestellt werden. 2.2 Wettbewerb und Kunden In diesem Kapitel sollen die Herausforderungen im Wettbewerbs- sowie Kundenumfeld eines Versicherungsunternehmens im digitalen Zeitalter skizziert werden. Die steigenden Herausforderungen sollen skizziert werden, um einen möglichen Handlungsbedarf für die Einführung einer Big-Data-Lösung im Versicherungsunternehmen zur Sicherung der Marktposition aufzuzeigen. 2.2.1 Wettbewerbsumfeld Im folgenden Kapitel sollen die verschiedenen neuen Anbieter im Versicherungsmarkt klassifiziert und die Bedeutung von InsurTechs beschrieben werden, um den zunehmenden Wettbewerbsdruck für ein Versicherungsunternehmen zu skizzieren. 16 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Eine der zentralen Herausforderungen neben der Veränderung des Kundenverhaltens ist der zunehmende Wettbewerb im Versicherungsumfeld. Nach Altuntas zeichnet sich ein stark zunehmender Markt- und Wettbewerbsdruck in der Versicherungsbranche ab (Altuntas P. M. & Uhl P. 2016, 23-29). Der gesättigte Versicherungsmarkt lässt kaum Wachstum in der Gesamtbranche zu. Neukundengewinnung läuft beruht nach Altuntas vielfach über Abwerbung. Versicherungsprodukte sind nicht patentierbar und lassen sich daher schnell kopieren. Die Situation für traditionelle Versicherungsunternehmen wird durch neue Anbieter verschärft. Neue Anbieter treten innerhalb der Branche auf, beispielsweise Direktversicherer oder InsurTechs sowie branchenfremde Akteure wie Automobilhersteller drängen in den Markt und Finanzdienstleister bieten Produkte in ähnlichen Kategorien an (Altuntas P. & Uhl P. 2016, 1). InsurTechs sind Start-Ups, die sich neue Technologien zu Nutze machen, sich entlang der Wertschöpfungskette platzieren und durch Vergleichsportale für den Kunden Transparenz schaffen (Rudolf B. 2016, 1). Der Begriff InsurTech setzt sich aus den Begriffen Insurance und Technology zusammen und wird von Dr. Nikolai Dördrechter N., Geschäftsführer von Policen Direkt wie folgt beschrieben: Definition: „InsurTech betrifft Versicherungsprodukte, deren Vertrieb und den laufenden Versicherungsbetrieb wird von neuen, nicht etablierten Unternehmen/Start-ups bzw. industriefremden Unternehmen angeboten. basiert auf neuen, digitalen Technologien zur Bereitstellung und Erbringung von Leistungen - also von Web-Technologien über neue Programmierverfahren bis hin zu DatenAnalysetechnologien, die bestimmte Geschäftsmodelle erst ermöglichen“ (Dördrechter N. 2016, 6). Branchenfremde Akteure wie Google oder Amazon könnten insbesondere im Bereich Policenvertrieb zur Konkurrenz für Versicherungen werden, da sie bereits über einen guten Kundenzugang verfügen und eine große Anzahl an Kundendaten sammeln. Nach Untersuchungen von Bankrate 2014 würden Käufer von Versicherungspolicen gerne von nicht-traditionellen Kanälen Gebrauch machen können wie beispielsweise Banken oder Amazon (Versicherungsbote 2014). Die beschriebene Platzierung entlang der Wertschöpfungskette wird bei der Analyse der Geschäftsmodelle neuer Anbieter deutlich: Anbieter werden unterschieden, in diejenigen, die sich auf das B2B-Segment konzentrieren, die digitale Vertriebswege nutzen, die Versicherungsvermittlungsplattformen in Kooperationen mit Versicherungen und die mit Makler kooperierenden Versicherungen in einer App konsolidieren (deutsche-startups.de 2016). Oliver Wyman veröffentlichte im Jahr 2016 einen Report über die „Zukunft von InsurTechs in Deutschland“. Hier werden in den Geschäftsmodellen „Angebot“ (Internet der Dinge, Neue digitale Risiken etc.), „Marketing/Vertrieb“ (B2B-Onlinemakler, Vergleichsportale etc.) und „Betrieb“ (Underwriting, Schaden etc.) jeweils mehr als 8 Start-Ups genannt, die Wertschöpfungsschritte traditioneller Versicherungen übernehmen und mit neuen Digitalkonzepten Kundenbedürfnisse vorgeblich besser bedienen (Dördrechter N. N. 2016, 12). Nach Aussagen von CORE Consulting gibt es mittlerweile 57 17 Bachelor Thesis Corinna Ludwig © CORE 2016 73 InsurTech Start-Ups in Deutschland (COREtechmonitor 2016), zehn InsurTech Start-Ups werden durch Venture Kapital unterstützt, über 40 Millionen Euro Venture Kapital wurde seit 2012 investiert (Barkow Consulting 2016). Das Online-Magazin Gruenderszene beschreibt die Revolution der Versicherungsbranche durch Start-Ups: Start-Ups nutzen Technologien wie Big-Data kundenorientiert, werden finanziell gefördert und entscheiden so über die Entwicklung der Branche (GruenderSzene 2016b). Während das Kerngeschäft der traditionellen Versicherungsunternehmen (Risikotransformation) weitestgehend unberührt geblieben ist, werden Fragmente der Wertschöpfungskette von Akteuren wie InsurTechs durch digital getriebene Geschäftsmodelle herausgelöst. Der mögliche Eintritt von bislang marktfremden aber technologisch und ökonomisch hoch befähigten Unternehmen wie Google und ihren datengetriebenen Geschäftsmodellen könnte diesen Trend potenzieren. 2.2.2 Kundenumfeld In diesem Kapitel sollen die veränderten Kundenbedürfnisse und das veränderte Kundenverhalten sowie die Schnittmenge von technologischen Entwicklungen und Kundenorientierung aufgezeigt werden. Diese Themen sollen erläutert werden, um die Bedeutung der Verzahnung von Technologien und Kundengewinnung hervorzuheben. Nach einer Aussage der Versicherungsforen Leipzig ist „der Kunde von heute immer vernetzt, stets informiert und anspruchsvoll“ (Wedekind K., Dormann B. & Lay U. 2016, 5). Die Veränderungen des Kundenverhaltens und -erwartungen stellte eine Herausforderung für die konservative Versicherungsbranche. Für die heranwachsende Kundengeneration, die „Generation Digital“, ist „der Umgang mit Technologien ein selbstverständlicher Teil des Alltags“ (Altuntas P. & Uhl P. 2016, 23). Kunden erwarten, dass Versicherungsunternehmen mit ihrem Leistungsangebot den veränderten Kundenbedürfnissen gerecht werden; einiger dieser Erwartungen wurden hier aufgezählt: Flexibilität: Möglichkeit der Anpassung der Versicherung, wenn sich Lebenssituation ändert, Individualität: Personalisierung der Versicherung ist erforderlich, Transparenz: Qualität und Preis müssen ersichtlich sein, Einfachheit: Der Aufbau der Versicherungsprodukte soll modular sein, also einfach und kombinierbar, Komfort: Verfügbarkeit und Erreichbarkeit von Ansprechpartnern beispielsweise Maklern muss gegeben sein, Schnelligkeit und Sicherheit: Die Bearbeitung von Versicherungsanträgen und Schadensmeldungen soll zeitnah und zuverlässig erfolgen. (Altuntas P. & Uhl P. 2016) Des Weiteren ändert sich das Verhalten der Kunden. Kunden nutzen technologische Möglichkeiten, interagieren auf unterschiedlichen Kanälen und informieren sich: 18 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Kunden informieren sich vor dem Abschluss unter anderem im Internet; Google verzeichnet einen Anstieg der Versicherungsthemen um 2,7 Prozent. Dieses Wachstum geht auf mobile Suchanfragen zurück, die um 44,3 Prozent zugenommen haben. Über mobile Endgeräte wie Smartphones erfolgen inzwischen 15,7 Prozent aller versicherungsrelevanten Abfragen. Der Abschluss erfolgt über verschiedene Kanälen, oft jedoch noch über den Makler vor Ort (ROPO Effekt: „Research Online, Purchase Offline). Mittlerweile werden schon 17Prozent der KFZ Verträge im Internet abgeschlossen. KFZ nimmt so eine Vorreiterrolle für den Direktabschluss im Internet ein (GDV 2015b). Markus Rosenbaum erklärte auf der Konferenz Digisurance im Jahr 2016, dass die größte Ineffizienz in der Versicherungsbranche die Kundenschnittstelle sei (Wedekind K., Dormann B. & Lay U. 2016, 5). Hier müssen sich traditionelle Versicherungen bei der Erfüllung der Kundenerwartungen an anderen Branchen messen, schneiden im Vergleich jedoch nicht gut ab (Zimmermann G. 2015, 91). Das Image der Versicherungswirtschaft ist nach Oletzky schlecht. Medienberichten zu Folge ist der Hauptgrund hierfür Intransparenz und mangelnde Verständlichkeit von Versicherungsunterlagen (Oletzky T., Staud N & Boltz J., 257-273). Der anspruchsvolle Kunde soll nicht nur analysiert werden können, um dessen Ansprüche besser erfüllen zu können, sondern auch um das Verhalten zur Risikoprävention messbar zu machen. In verschiedenen Bereichen entlang der Wertschöpfungskette gibt es bereits Möglichkeiten, um die Betrachtung des Kunden in der eigenen Unternehmensstrategie mit technologischer Unterstützung auf der Basis von Daten zu berücksichtigen. Versicherungen integrieren die digitale Welt beispielsweise in ihren Vertriebsstrategien. Diese sollten unter anderem die Integration digitaler Vertriebskanäle in die Vertriebslandschaft, die Analyse des Kunden über eine 360-Grad-Sicht und die Bereitstellung der nötigen IT-Landschaft beinhalten, um den anspruchsvollen Kunden analysieren zu können (Binckebanck L. & Elste R. 2016, 266). Insbesondere im Zuge der Nutzung von digitalen Vertriebskanälen gewinnt das Sammeln und Auswerten von Kundendatenmengen zunehmend an Bedeutung. Digitale Vertriebskanäle stellen neue Datenquellen und einen neuen Interaktionsweg für den Kunden dar (Binckebanck L. & Elste R. 2016, 268). Auch im Bereich der Produktentwicklung leisten digitale Technologien einen ersten Beitrag zur Neuausrichtung der Produkt- und Preispolitik. Sensoren liefern Daten über den Fahrstil an die Kfz-Versicherung; wer umsichtig fährt, bekommt Rabatte vom Versicherer. Der Kunde erhält ein individualisiertes Produkt. An dieser Stelle ist gleichermaßen wie im Vertrieb die Datengrundlage entscheidend. Werden technologische Entwicklungen im Risikobereich und Schaden betrachtet, wird erkennbar, dass hier neue intelligente Computersysteme zur Entscheidungsfindung dazu beitragen, beispielsweise Risiken der Kunden bei der Antragsprüfung besser einschätzen zu können und Schadensquoten zu reduzieren. Hierzu ist die Analyse von großen Datenmengen notwendig. (GDV 2016) 19 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Festzuhalten bleibt, dass sich Kundenbedürfnisse und -verhalten im digitalen Zeitalter geändert haben und der gemeinsame Nenner der Anwendungsfälle für die Verbesserung der Kundeneinsicht und der Adressierung der Bedürfnisse die Analyse steigender Datenmengen bildet. Aus den Kapiteln Wettbewerb und Kunden ist festzustellen, dass die Herausforderungen für ein Versicherungsunternehmen steigen: Das Unternehmen konkurriert auf der einen Seite mit Anbietern, die sich neue Technologien zu Nutze machen und steht auf der anderen Seite einer heranwachsenden digitalen Generation gegenüber. 20 Bachelor Thesis Corinna Ludwig © CORE 2016 73 3 Theoretische Grundlagen: Technologien Das folgende Kapitel strukturiert sich wie folgt: Einführung in die Theorie von Software-Architekturen, Beschreibung des Big-Data-Ökosystems. Die Beschreibung des Kapitels Software-Architektur ist notwendig, um die Einführung einer neuen Software-Architektur für die Stakeholder einordnen zu können. Die Beschreibung des BigData-Ökosystems dient der Herleitung der Architekturentscheidung im Big-Data-Kontext. 3.1 Software-Architekturen In diesem Kapitel soll der Begriff Software-Architektur näher erläutert, der Software-ArchitekturLebenszyklus, das Konzept einer Architekturbeschreibung und die Qualitätsanforderungen an eine Architektur skizziert werden. Der Lebenszyklus und das Konzept der Architekturbeschreibung dienen der Einordnung der Architekturerstellung entlang des Architekturentscheidungsprozess. Die Qualitätsanforderungen bieten die Grundlage für die Klassifikation der Anforderungen an eine Architektur. Für die Entwicklung von komplexen Softwaresystemen hat sich das Konzept der Software-Architektur etabliert und ist Teil des Softwarelebenszyklus. Software-Architektur und -design schließen sich der Anforderungsanalyse als erste technische Aktivität an (Heinrich G. 2007,43). In der Existenz von verschiedenen Werken namhafter Autoren, beispielsweise Bass, Clements, und Kazman „Software Architecture in Practice“ sowie internationalen Konferenzen wie WICSA manifestiert sich die Bedeutung von dem Konzept Software-Architektur als etablierte Disziplin. Was verbirgt sich hinter dem Begriff Software-Architektur? Es gibt keine Standard-Definition von Software-Architektur (Babar, M. A., Zhu, L.& Jeffery, R. 2004, 1). An dieser Stelle wird die Beschreibung von Clements P. herangezogen: Definition: „Software-Architektur für ein System als Struktur oder Strukturen des Systems, das aus den Elementen selber , deren von außen erkennbare Eigenschaften und den Beziehungen zwischen den Elementen besteht“(Clements P. u.a. 2011, 5). Welche Rolle spielt die Software-Architektur? Eine Software-Architektur hat einen unterrichtenden Charakter und stellt einen Weg dar, um die Kommunikation zwischen den verschiedenen Stakeholdern - Architekten, Designer, Entwickler, Manager etc. - zu ermöglichen. Die Architektur bildet die Basis für die weitere Systemanalyse und das Systemdesign (Clements P. u.a. 2008, 1). Informationen sollen beispielsweise über die Erfüllung von Qualitätsmerkmalen dargestellt werden, um später evaluiert werden zu können (Clements P. u.a. 2001, 1). Barry Boehm, Software Engineering Professor an der University of Southern California und bekannt für das Constructive Cost Model (COCOMO), das Spiral-Modell des Softwareprozesses und die W-Theorie (Boehm B. 2012), beschrieb die Wichtigkeit der bedachten Entscheidung für 21 Bachelor Thesis Corinna Ludwig © CORE 2016 73 eine Software-Architektur in der Keynote „And a Very Few Lead Bullets Either”: „Marry your architecture in haste and you can repent in leisure“ (Clements P., Kazman R. & Klein M. 2002, 1). 3.1.1 Der Software-Architektur-Lebenszyklus Das Vorgehen für das Erstellen einer Software-Architektur - der Software-Architektur-Lebenszyklus - lässt sich nach Posch in drei Bereiche gliedern: Vorbereitungen für den Entwurf, Entwurf, Dokumentation und Bewertung sowie Umsetzung der Architektur (Posch, Birken & Gerdom 2004). Die genauere Untergliederung wird in der Abbildung 2 beschrieben. Abbildung 2: Software-Architektur-Lebenszyklus (Quelle: eigene Darstellung in Anlehnung an Posch, Birken & Gerdom 2004, 53) 3.1.2 Das Konzept einer Architekturbeschreibung In diesem Kapitel sollen die Interdependenzen der Begriffe des Konzepts einer Architekturbeschreibung und das etablierte Konzept der Architektur-Sichten beschrieben werden. Zunächst soll der Begriff der Architekturbeschreibung in den Kontext gesetzt werden. Ein „System“ beschreibt eine Zusammenstellung von Komponenten, um einer bestimmten Funktion zu dienen. Das System ist Teil einer „Umwelt“ (engl. Environment). Die Umwelt beeinflusst die Rahmenbedingungen für die Entwicklung und definiert den Scope des Systems. Andere Systeme können Teil der Umwelt sein. Es gibt verschiedene Stakeholder, die ein Interesse an der Entwicklung des Systems haben. Beispielsweise sind das in einer Versicherung der IT-Abteilungsleiter, der IT-Architekt oder der Vor- 22 Bachelor Thesis Corinna Ludwig © CORE 2016 73 stand. Als „Anliegen“ (engl. concern) werden diejenigen Interessen beschrieben, die die Systementwicklung direkt tangieren. Anliegen sind unteranderem systemrelevante Überlegungen, die Qualitätsmerkmale wie Performance, Sicherheit und Zuverlässigkeit betreffen. Ein System soll ein oder mehrere „Missionen“ adressieren, die eine Zielbündelung der Interessen von Stakeholdern beschreibt. Eine Architektur kann durch eine Beschreibung erfasst werden. (Sherlund B. u.a. 2000, 5) Hier hat sich das Konzept von Architektursichten in der Praxis bewährt. Sichten (engl. View) beschreiben ein Set von Elementen und deren Beziehungen und eine Software-Architektur aus einem bestimmten „Standpunkt“(engl. viewpoint) (Clements P. 2005, 3). Jede Sicht inkludiert ein oder mehrere Anliegen der Stakeholder. Die Konventionen für die Entwicklung einer Sicht werden im Standpunkt festgelegt. Hier werden Notationen, Modell und Analysetechniken festgelegt. Die Architekturbeschreibung besteht aus einer oder mehr Sichten je nach Anliegen der Stakeholder. Bereits definierte Standpunkte werden von Sherlund als „Standpunkte der Bibliothek“ (engl. library viewpoint) bezeichnet. Eine Sicht kann aus verschiedenen Architekturmodellen bestehen. Hier werden die Standpunkte verwertet. Ein Architekturmodell kann mehr als einer Sicht zugeordnet werden. In dem Journal Recommended Practice for Architectural Description of Software Intensive Systems von Clements P. wird das Konzept einer Architekturbeschreibung einmal modellhaft dargestellt, um den Gesamtkontext zu erfassen. (Sherlund B. u.a. 2000, 5) Für die Beschreibung von Software-Architekturen ist das Verständnis von den bereits erwähnten drei Schlüsselbegriffen essentiell: Architektur-Sicht, Architektur-Perspektive und Architektur-Stil. Die drei Schlüsselbegriffe werden zu dem etablierten Konzept für Architektur-Sichten zusammengefasst. (Clements P. u.a. 2001) Mit Hilfe von Architektur-Sichten kann ein konkretes System beschrieben werden (Clements P. P. u.a. 2001, 38). In verschiedenen Sichten werden unterschiedliche Qualitätsmerkmale adressiert. Beispielsweise können anhand einer „Schichten-Sicht“ Modifizierbarkeit und somit Portabilität ersichtlich gemacht werden. Eine „Prozess-Sicht“ hingegen stellt die Performance-Frage in den Vordergrund. Verschiedene Autoren haben unterschiedliche „Sets für Sichten“ (=Standpunktmengen) definiert, beispielsweise die „4+1 Sicht“ von Kruchten oder die „Siemens 4 Sicht“ (Clements P. u.a. 2001). Die 4+1 Sicht unterscheidet zwischen der“ logischen, der prozessualen, der physischen und der Entwicklungssicht“. Die Siemens 4 Sicht hingegen gliedert die Architektursichten in die „konzeptionelle, die modellinteraktionsgetriebene, die ausführende und die Codesicht“ (Clements P. u.a. 2001, 42). Der aktuelle Trend geht jedoch dahin, keine festen Sets zu definieren. Zur Dokumentation einer Architektur können die Richtlinien der IEEE 1472 - Norm IEEE 1471-2000: Software-Architekturbeschreibung mit dem Titel „IEEE Recommended Practice for Architectural Description of Software-Intensive Systems“- herangezogen werden. Hier werden die für den Stakeholder relevanten Sichten dokumentiert (IEEE 2000). 23 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Dieser Ansatz wird auch „Views-and-Beyond “ genannt und besagt: Definition: „Die Dokumentation einer Architektur ist abhängig von der Dokumentation der relevanten Sichten, um dann die für mehrere Sichten übergreifende Dokumentation ergänzen zu können“ (Clements P. u.a. 2008, 1). Die Architektur-Perspektive beschreibt nach Clements P. die die Bausteinarten und Relationstypen, um die Architektur eines Softwaresystems aus einer bestimmten Perspektive zu beschreiben. Im Zuge der Auswahl der Perspektive werden die Elementtypen und die zugehörigen Beziehungsarten eingeschränkt. Hier wird zwischen drei „für das System natürlichen“ Perspektiven unterschieden: „Module“, „Komponente-und-Konnektor“ und „Allokation“. Mit Hilfe der Perspektive Module können die Einheiten einer Implementation dargestellt werden. Die Komponente-undKonnektor-Perspektive bildet die auszuführenden Systemeinheiten ab. In der Allokations-Perspektive wird die Beziehung zwischen Ausführungs- und Entwicklungsumgebung mit dessen Softwaresystem beschrieben (Clements P. u.a. 2008, 4). Unter dem Begriff Architektur-Stile werden wiederverwendbare Architekturmuster zusammengefasst. Die Kommunikation zwischen den Elementen wird beschrieben sowie die Verteilung der Aufgaben. Hier wird beschrieben, wie die Elemente zusammenspielen und welche Restriktionen es gibt. Für die Perspektive „ Module“ gibt es beispielsweise den Schichten-Stil, für Komponenteund-Konnektor den Client-Server-Stil und der Implementations-Stil für die Allokations-Perspektive dar. (Clements P. u.a. 2008, 4) Mit jeder Perspektive werden unterschiedliche Architektur-Stile assoziiert. Mit Hilfe von Architekturstilen werden die Entscheidungen getroffen, welche der im Stil gefassten Elemente in den Elementen des Systems, den Sichten, verankert werden (Clements P. u.a. 2001, 38). Stile werden in einem Style-Guide festgehalten und können mit der verbreiteten vereinheitlichten Modellierungssprache Unified Modeling Language (UML) visualisiert werden (Clements P. u.a. 2008, 1). Stile sind somit ausdifferenzierte Perspektiven; Sichten beschreiben die konkrete Anwendung von Stilen bei einem System. Verschiedene Stile werden in der Praxis in Referenzarchitekturen kombiniert, die einzelnen Stile können nur noch bedingt identifiziert werden. Auch hier werden auf Grund der Individualität der Anforderungen für verschiedene Stakeholder unterschiedliche Sichten mit unterschiedlichem Detaillierungsgrad aufbereitet (Clements P. u.a. 2008,1). Die architektonische Beschreibung von IT-Systemen kann mit Hilfe der dargestellten Begrifflichkeiten und Konzepte formalisiert erfolgen. Ihre Sichten, Perspektiven und Stile ermöglichen den Stakeholdern eine umfassende Kenntnis der Systeme. In der Folge der Arbeit soll auf dieses konzeptionelle Gerüst aufgesetzt werden. 3.1.3 Qualitätsanforderungen an eine Software-Architektur In diesem Kapitel sollen Qualitätsanforderungen klassifiziert und die Architekturevaluationsmethode ATAM dargestellt werden. In der Praxis determinieren Qualitätsanforderungen an ein System seine Ausgestaltung. Diese dienen somit auch als Eckpfeiler für Software-Architektur-Evaluationsmethoden. Eine der be- 24 Bachelor Thesis Corinna Ludwig © CORE 2016 73 kanntesten Architekturevaluationsmethoden ist die ATAM-Methode. Sie wird nach der Entscheidung für eine Referenzarchitektur eingesetzt. Im Zuge der Anwendung der ATAM-Methode werden die Abhängigkeiten von Qualitätsmerkmalen untersucht (Clements P. u.a. 2008, 239). Der Fokus liegt hier insbesondere auf der Identifikation von Risiken sowie Überprüfung von Anforderungen an konkreten Szenarien. Die Risiken werden in Sensitivitätspunkte (engl. sensitivity points) und Abwägungspunkte (engl. tradeoff Points) unterteilt (Malich S. 2008, 84). Sensitivitätspunkte beschreiben Eigenschaften von Softwareelementen, die kritisch sind für die Erreichung eines einzelnen Qualitätsmerkmals. Abwägungspunkte hingegen sind Eigenschaften, die kritisch sind für die Erreichung mehrerer Qualitätsmerkmale (Malich S. 2008, 85). Die ATAM Methode lässt sich in folgende vier Phasen aufteilen: Präsentation: Austausch von Informationen über die bestehende Architektur und Anforderungen, Investigation & Analyse: Bewertung der Qualitätsanforderungen im Zuge der Architekturbetrachtung, Testen: Vergleich der Analyseergebnisse mit den Anforderungen der Stakeholder Reporting: Zusammenfassung der Ergebnisse. (Clements P., Kazman R. & Klein M. 2002, 44) Die Qualitäts-Standards für die in der Architektur beschriebenen Softwaresysteme wurden im ISO/IEC-Standard 9126 zunächst definiert und sind dann in der Norm ISO/IEC 25000 (ISO 2011) aufgegangen. Für unterschiedliche Use-Cases werden verschiedene Qualitätsanforderungen herangezogen. In der nachfolgenden Tabelle werden die Qualitätskriterien klassifiziert nach Charakteristika und Sub-Charakteristika der ISO-Norm aufgelistet. 25 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Charakteristika Sub-Charakteristika Funktionalität Angemessenheit Genauigkeit Interoperabilität Sicherheit der Funktionalität Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit Konformität der Zuverlässigkeit Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Konformität der Zuverlässigkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Konformität der Benutzbarkeit Effizienz Zeitverhalten Verbrauchsverhalten Konformität der Effizienz Wartbarkeit Analysierbarkeit Änderbarkeit Stabilität Testbarkeit Konformität der Wartbarkeit Portabilität Anpassbarkeit Installierbarkeit Koexistenz Austauschbarkeit Konformität der Portabilität Tabelle 1: Qualitätskriterien Software-Architektur (Quelle: eigene Darstellung in Anlehnung an Rochimah et al. 2015) Bei jeder Architekturentscheidung sind mehrere konzeptionelle Aufgaben zu beachten, um an einem frühen Punkt im Softwarelebenszyklus die Erfüllung der Anforderungen sicherzustellen. Die Interdependenzen zwischen Stakeholdern und deren Anliegen sind bei der Systementscheidung zu berücksichtigen. Unter zu Hilfenahme von Architekturstilen können verschiedene Sichten eines Systems betrachtet werden. Darüber hinaus müssen Qualitätsanforderungen erfüllt werden. 26 Bachelor Thesis Corinna Ludwig © CORE 2016 73 3.2 Big-Data-Technologien In diesem Kapitel werden die theoretischen Grundlagen zum Verständnis der technologischen Basis für Big-Data gelegt. Zur Einleitung in das Thema werden verschiedene Big-Data-Definitionen vorgestellt. Neue Entwicklungen im Bereich der Datenmodelle werden anhand der Einführung von No-SQL sowie ihrer Abgrenzung zu tradierten relationalen Modellen aufgezeigt. Die Kenntnis der Daten ermöglicht in der Folge die Klassifikation von Daten und ihrer Einordnung ein einen Datenlebenszyklus. Die Vielfalt an Daten erfordert zusätzlich eine Beschreibung der Schichten und Bausteinen einer Big-Data-Lösung. Auf Basis dieses theoretischen Fundaments werden Big-Data-Referenzarchitekturen und ihre Prinzipien vorgestellt. Zu weiteren Analyse werden die Referenzarchitekturen Lambda- und Kappa ausgewählt und detailliert. 1997 beschrieben die NASA Forscher Cox und Ellsworth in ihrem Report, dass Computersysteme bei Simulationen ihre Grenzen erreichen. Sie bezeichnen das Phänomen als „Big-Data“ (Cox M. & Ellsworth D. 1997). Verschiedenste Assoziationen verbindet die Gesellschaft mit dem Phänomen Big-Data: Die Datenhoheit und Macht der IT-Konzerne, die verallgemeinerte Beschreibung der Verarbeitung von großen Datenmengen und der Auftrieb von neuen Technologien. Jedoch gibt es keine allgemein akzeptierte Definition für dieses Phänomen. Unter dem Begriff Big-Data subsummiert sich nach Dorschel J. eine „Vielfalt von Technologien, Analytischen Methoden, Modellierungs- und Designverfahren, Kommerzieller Konzepte, Rechtlicher Rahmenbedingungen“ (Dorschel J. 2015, 2). Das Phänomen kann nach Dorschel J. aus dem gesellschafts-und politischen, technischen sowie ökonomischen Standpunkt heraus beleuchtet werden (Dorschel J. 2015, 2). In dieser Arbeit soll Big-Data aus einem technischen Standpunkt betrachtet werden. Vorab soll geklärt werden, warum ein Unternehmen sich mit dem Thema Big-Data beschäftigen sollte. Die Chancen, die sich durch Big-Data ergeben, werden in dem Report „Big-Data im Praxiseinsatz - Szenarien, Beispiele, Effekte“ der BITKOM dargestellt und in folgenden Tabelle beschrieben (BITKOM 2012, 14) Aspekt Erläuterung Big-Data-Strategie Zunehmende Datenvolumina liefern Argumente für die Bedeutung der Daten und regen das Management an, strategische Antworten für die erfolgreiche Nutzung Daten und Technologien zu entwickeln. Governance Durch die Festlegung klarer Verantwortlichkeiten ist Transparenz zu schaffen. Ein zeitnaher Zugang zu Big-Data für alle Beteiligten erschließt Innovationspotenzial und fördert neue Wertschöpfung. Prozessoptimierung Fortgeschrittenes Datenmanagement bildet die Voraussetzung für die Prozessoptimierung. Die Bereitstellung von Informationen in Echtzeit ist die Grundlage für völlig neue Geschäftsprozesse. Compliance Das wachsende Datenvolumen sowie die Komplexität der Daten stellen hohe Anforderungen an die Compliance. Ein transparentes Daten- 27 Bachelor Thesis Corinna Ludwig © CORE 2016 73 management einhergehend mit der detaillierten und zeitnahen Aufbereitung vorgeschriebener Informationen erleichtert die Erfüllung regulatorischer Anforderungen. Kundenkenntnis Big-Data versetzt Unternehmen in die Lage, Kundensegmente mit größerer Granularität im Auge zu behalten und somit Produkt- und Serviceangebote besser am realen Bedarf auszurichten. Angemessene Ent- Neue Formen der Datenauswertung und -aggregation liefern Informa- scheidungsbasis tionen mit bisher nicht erreichter Spezifikationen. Die Analyse der explodierenden Datenmengen erleichtert fundierte Management-Entscheidungen zum bestmöglichen Zeitpunkt. Die Analyse komplexer Datensätze in Verbindung mit problemadäquater Interpretation der Ergebnisse verbessert Entscheidungen als zunehmend automatisierter Prozess, oft in Echtzeit. Die Verknüpfung unterschiedlicher Datenformate unterstützt völlig neue Erkenntnisse. Time-to-Market Mit dem frühzeitigen Erkennen von Marktveränderungen wird Reagieren zunehmend durch Agieren ersetzt. Geschäftsmodelle Big-Data lässt Unternehmen nicht nur bestehende Angebote verbessern, sondern völlig neue Angebote entwickeln. Tabelle 2: Chancen durch den Einsatz von Big-Data (Quelle: BITKOM 2012, 5) 3.2.1 Verschiedene Definitionen zu Big-Data Wie bereits beschrieben, ist die Definition von Big-Data nicht allgemein akzeptiert und wird durch Technologie-Unternehmen insbesondere zum Marketing ihrer jeweiligen Software verwendet. In der Folge soll mit einer Reihe von gängigen Definitionen die Spannweite des Begriffes illustriert werden. Diese Definitionen zeichnen sich vielfach jedoch dadurch aus, dass sie vielfach ohne größere theoretische Einordnung auskommen oder Teilaspekte besonders betonen. Sie dienen zur Überleitung zum 5 V-Modell, das in der Folge erläutert und für die weitere Betrachtung zu Grunde gelegt wird. Die Apache Software Hadoop stellt beispielsweise die Kerntechnologie und Komponenten für große Datenverwertung und Datenanalysen dar. Big-Data ist jedoch nicht nur auf den Einsatz von Hadoop zu beschränken. Der Begriff Big-Data jedoch umfasst ein Konstrukt von Komponenten, um Datenhaltung, -verarbeitung und -visualisierung sowie Bereitstellung von Ergebnissen an nachfolgende Applikationen zu ermöglichen. Alle in Beziehung mit Daten stehenden Prozesse werden so durch Big-Data unterstützt. Der Begriff umfasst somit mehr als den reinen Technologiestack (Demchenko Y., Laat C. & Membrey P. 2014, 1). Die erste Definition von Mike Gualtieri hebt den Analytics-Aspekt von Big-Data hervor. Die verstärkte Nutzung wissenschaftlicher Methoden von Unternehmen im Zuge der Big-Data Entwicklung findet sich in der folgenden Beschreibung von Mike Gualtieri wieder: Definition 1: „Firmen realisieren, dass sie präskriptive und deskriptive Analysen nutzen müssen, um den Wert von Informationen feststellen zu können. Im Zuge der Anwendung von fortgeschrittene Big-Data Analysemethoden werden weitergehende Statistik, Data Mining und Algorithmen 28 Bachelor Thesis Corinna Ludwig © CORE 2016 73 des maschinellen Lernens verwendet, diese gehen weit über traditionelle Business Intelligence Tools, einfachen Queries oder Regeln hinaus“ ((Demchenko Y., Laat C. & Membrey P. 2014, 2). Welches Phänomen wird hier beschrieben? Big-Data hat verschiedene Auswirkungen in der Forschung sowie in der Industrie. In e-Science wird sich herkömmlich mit den Herausforderungen von großen Datenmengen als Ergebnis des wissenschaftlichen Forschungsprozesses beschäftigt. Die Sammlung von Daten ist die Grundlage für Hypothesenverifizierung und Modellbildung. Hier werden Daten zwischen verschiedenen Forschungszentren geteilt, um komplexe Probleme lösen zu können. In der Industrie werden kaum Daten geteilt; die Unternehmen haben das Ziel, ihre Datenhoheit zu behalten. Datensicherheit spielt hier eine große Rolle, unter anderem wenn Unternehmen auf Drittanbieter, die beispielsweise Clouds bereitstellen, zurückgreifen. Für Unternehmen stellt die Nutzung von Big-Data Technologien eine Herausforderung dar. Um von BigData- Technologien profitieren zu können, muss auf wissenschaftliche Methoden zurückgegriffen werden. So können Daten ausgewertet werden, um Kundenverhalten vorherzusagen oder Marktentwicklungen abschätzen zu können. (Demchenko Y., Laat C. & Membrey P. 2014, 1). Das Unternehmen IDC charakterisiert Big-Data folgendermaßen: Definition 2: „Neue Generationen von Technologien und Architekturen, die dazu designed worden sind ein hohes Volumen einer Varietät an Daten zu extrahieren und so Analysen, Entdeckungen und schnelle Datenerfassungen möglich zu machen“ (Demchenko Y., Laat C. & Membrey P. 2014, 1). Die Herausforderungen durch Big-Data werden von Jason Bloomberg in der nachfolgenden Definition beschrieben: Definition 3: „Big-Data: das steigende Volumen von strukturierten und unstrukturierten Daten hat zur Folge, dass die Verarbeitung nicht mehr durch traditionelle Datenbanken und Software realisiert werden kann“ (Demchenko Y., Laat C. & Membrey P. 2014, 2). Als Eckpfeiler für neue Analyseverfahren, Technologien, Architekturen und Herausforderungen dient die Beschreibung der zugrundeliegenden Charakteristika der Daten. In der Zusammenfassung der praxisgetriebenen Definitionen wird deutlich, dass neben steigenden Datenvolumen ihre Auswertung eine herausgehobene Rolle spielt. 3.2.2 Bekannteste Definition von Big-Data: Das 3-V-Modell Um die Einschränkungen praxisorientierter Definitionen - insbesondere bezüglich der Auswertung wachsender Datenvolumen - zu verbessern, haben Unternehmen der Beratungsbranche stärker konzeptorientierte Definitionen vorgelegt. Das 3V-Modell ist ein verbreitetes Konzept, das hier vorgestellt und diskutiert werden soll. Eine der bekanntesten Definitionen für Big-Data stammt von Gartner und geht auf den Forschungsbericht des Analysten Doug Laney zurück. Definition 4: Diese besagt, dass Big-Data „ein High-Volume, High-Velocity und High-Variety Informationsbestand ist, der Kosteneffektivität, innovative Ansätze der Informationsverwertung für verbesserten Insight und Entscheidungsfindung verlangt“ (Laney D. 2001, 3). 29 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Diese Definition charakterisiert Big-Data anhand von den drei beschriebenen V’s: „Volume“,“Velocity“ und „Variety“ (Laney D. 2001, 3). Die verschiedenen Dimensionen sind in Abbildung 4 erkennbar. Einzelne Schichten des Kreises werden zu einem späteren Zeitpunkt noch einmal aufgegriffen und erklärt. Viele der hier genannten Aspekte - neue Analytics-Methoden, neue Technologien, Architekturen, Datenformen, Datencharakteristika - werden in dem Versuch der umfassenderen Beschreibung von Big-Data wieder aufgegriffen; sie zeigen gleichzeitig die fehlende Einheitlichkeit der Beschreibung des Big-Data-Phänomens in der Literatur. Abbildung 3: Dimensionen von Big-Data: Das 3-V-Modell (Quelle: eigene Darstellung in Anlehnung an Khaki S. 2016) 3.2.3 Einführung in No-SQL Datenmodelle Zur Strukturierung der Daten in Big-Data werden Datenmodelle entworfen, wobei hier ebenfalls neue Konzepte entwickelt werden. Im folgenden Kapitel soll das Konzept No-SQL erläutert werden sowie ihre herausgehobenen Ausprägungen bezüglich der Datentypen, Datenformate und Datenzustände. Die Betrachtung dieser Elemente ermöglicht in der Folge die Bewertung einer Big-Data Architektur entlang ihrer datenbezogenen Leistungsfähigkeit. Im Zuge der wachsende Datenmenge, insbesondere an unstrukturierten Daten, stoßen traditionelle relationale Datenmodelle an Leistungsgrenzen, was unter anderem die NIST Big-Data Public Working Group feststellt (NIST 2015, 6). In relationalen Datenmodelle werden eine Sammlung von Relationen in Tabellen abgebildet, jede Tabelle ist ein Datensatz, jede Zeile ein Tupel 30 Bachelor Thesis Corinna Ludwig © CORE 2016 73 und jede Spalte ein Attribut (= Eigenschaften eines Tupels). (Codd E. 1990, 28) Alle grundlegenden Operationen -Abspeicherung, Abfrage und Veränderung der Daten- können durch relationale Algebra - ein algebraisches Modell - beschrieben werden. durch Wichtiger Bestandteil relationaler Datenmodelle ist das feste Schema. Das Schema legt fest, welche Daten in der Datenbank gespeichert werden und wie diese Daten in Beziehung zueinander stehen. Zur Abfrage wird die Datenbanksprache SQL (= Structured Query Language) verwendet. (Codd E. 1990, 91) Die Entwicklung flexibler Schemata wird erforderlich und No-SQL Datenmodelle bieten eine Antwort auf die wachsende Vielfalt, das Volumen und die Velocity von Daten. No-SQL steht für Not-OnlyStructuredQueryLanguage und beschreibt die Existenz von logischen Datenmodellen, die die Paradigmen von relationaler Algebra ergänzen und die Schema-Notwendigkeit ablösen. Daten können in NoSQL Datenmodellen in Form von Dokumenten, Graphen, Key-Value-Paaren oder Spalten gespeichert werden (Gomez P. , Casallas R. & Roncancio C. 2016, 1) Die Gestalt der Daten -beispielsweise Datentyp oder Datenformat - diktiert die Ausgestaltung des Datenmodells. Die Kombination aus unterschiedlichen Modellen ist möglich und sollte individuell entschieden werden. Die Auswahl des Datenmodells ist maßgebend für die Auswahl der Architektur und der einzelnen Komponenten (NIST 2015, 6). Bevor die Weiterentwicklung des 3-V-Modells zu einer umfassenderen Definition von Big-Data beschrieben wird, muss ein grundsätzliches Verständnis über die verschieden vorliegenden Daten innerhalb des Big-Data Konzepts beschrieben werden. Die Daten werden im nächsten Abschnitt klassifiziert. Der Abschnitt strukturiert sich wie folgt: Zunächst werden Schlüsselkonzepte von Daten im Big-Data-Konzept beschrieben, anschließend werden Daten weiter klassifiziert und schließlich werden allgemeine Anforderungen an ein Datenmodell skizziert. Dieser Abschnitt ist grundlegend für die in der Abbildung 2 (Software-Architektur-Lebenszyklus) im Kapitel 3.1 Software-Architekturen beschriebene Anforderungsspezifikation. Datentyp-Metadaten Individuelle Datenelemente unterliegen keiner Veränderung durch Big-Data. Ein wichtiges Konzept von Big-Data sind Metadaten. Metadaten beschreiben ergänzende Informationen über Daten, beispielsweise wie und wann sie gesammelt und verwertet worden sind. Metadaten sind für Big-Data Analysen entscheidend, da durch sie eine Verringerung der Menge und leichtere Datenauswertung möglich ist. Der Blogger Christian Schön beschreibt Metadaten wie folgt: „ Zu früheren Zeiten legten Archivare Zettelkästen an, um den Aufenthaltsort von Dokumenten und Büchern in Archiven schnell zu finden. (…) Metadaten sind digitale Archivare“ (Schön C., 2015). Datencontent-Format: Strukturierte, unstrukturierte, semi-strukturierte Daten Datenelemente werden in Datensätzen zusammengefasst, die eine Transaktion, eine Beobachtung oder ein Event beschreiben. Es wird zwischen strukturierten, unstrukturierten und semistrukturierten Daten unterschieden. Strukturierte Daten können in relationalen Datenbanken effizient beschrieben werden und bezeichnen Daten mit gleichartiger Struktur. Unstrukturierte Daten bzw. semi-strukturierte Daten liegen nicht in geordneter Form vor. Zu den Datentypen zählen beispielsweise Texte, Videos und Bilder (NIST 2015). 31 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Datenzustand- Data at Rest, Data-In-Motion Datensätze (engl. data records) können in Datenbestände (engl. data sets) gruppiert werden, die verschiedene Big-Data Charakteristiken aufweisen. Datenbestände können zwischen den Daten an sich, gespeicherten Daten (engl. Data at Rest) und Daten bei der Übertragung bzw. Datenströmen (engl. Data-In-Motion) unterschieden werden. (NIST 2015) Data at Rest sind Informationen, die aus verschiedenen Quellen gesammelt und abgespeichert worden sind. Diese Daten werden nach dem Event analysiert, bei dem sie angefallen sind somit separat. Data-In-Rest beschreiben also zu persistierende Daten. Bei Data-In-Motion ist der Analysezeitpunkt ein anderer. Die Daten werden gesammelt und während der Event stattfindet in Echtzeit analysiert. Data-InMotion referenzieren auf zu prozessierende Daten. Das Spektrum an Datenformaten, logischen Modellen, Zeitskalen und Semantik soll in Analysen verarbeitet werden können (Internap 2014). Bei der Betrachtung von Data-In-Motion ist das Zeitfenster von Relevanz, in dem Daten verarbeitet und analysiert werden können. Hier wird zwischen Echtzeit und Nahezu-Echtzeit unterschieden. Die Schlüsselkonzepte von Daten im Big-Data-Kontext wurden vorgestellt. Bei der Erstellung eines Datenmodells zur Klassifizierung einer Big-Data-Lösung sind nach Aussagen der Firma IBM weiterhin die folgenden Kategorien zu beachten: Datenquelle: beispielsweise Web und Social Media, biometrische Daten, Transaktionsdaten oder maschinell generierte Daten, Datenfrequenz: beispielsweise Zeitreihen, Echtzeit-Übertragungen, kontinuierliche Übertragungen, Stichtagsbetrachtungen oder On-Demand-Übertragungen, Datentyp: beispielsweise Metadaten, Masterdaten, historische Daten, transaktionale Daten, Datencontent-Format: strukturierte Daten, unstrukturierte Daten oder semi-strukturierte Daten, “Daten-Consumer”: Business Prozesse, andere Repositories oder Applikationen. (Mysore D.). Die Grundlagen für die Spezifikation der Daten wurden gelegt. Marz beschreibt zudem die weiteren Anforderungen, die ein Datenmodell im Big-Data-Kontext erfüllen muss: Daten sollten im Rohzustand vorliegen, Daten sollten unveränderlich sein, Daten sind „eternally true“ (Marz N. & Warren J. 2015, 36). Die Kenntnis über die Art der zu speichernden, zu prozessierenden sowie zu analysierenden Daten ist für die Definition eines spezifischen Datenmodells als Eckpfeiler für eine Big-Data-Lösung und der damit einhergehenden Entscheidung für ein Speichermedium, die Art des DatenZugriffs, die Datenintegration sowie der analytischen Verarbeitung und somit Big-Data-Architektur relevant. (NIST 2015, 6) 32 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Die Kenntnis der Datenmodelle und ihrer Ausprägungen Datentyp, Datenformat, und Datenzustand wird durch No-SQL-Modelle erweitert. Dies ermöglicht Leistungssteigerungen für Big-DataSysteme. Gleichzeitig bieten sie die Grundlage zur Bewertungen der assoziierten Architekturen. 3.2.4 Das Big-Data-Ökosystem: Das 5-V-Modell Die von Gartner im 3-V-Modell beschriebenen Big-Data-Eigenschaften sowie die vorangegangene Klassifizierung von Daten bieten einen ersten Ansatzpunkt für die Forcierung dieser datengetriebenen Modelle. Sie stellen High-Level-Anforderungen an eine Big-Data-Architektur dar und sind Grundlage für das Datenmodell. Das Modell wird in der Folge erläutert. Der Ansatz von Gartner wurde im Journal „Adressing Big-Data Issues in Scientific Infrastructure“ weiterentwickelt. Hier wird Big-Data anhand von 5 V’s charakterisiert: „Volume“, „Velocity“, „Variety“, „Veracity“ und „Value“ (Demchenko Y., Laat C. & Membrey P. 2014, 2). Diese Charakteristika bieten die Grundlage für die systematische Herleitung der Definition des Big-Data-Ökosystems. Das Paper „Defining Architecture Components of the Big-Data Ecosystem” greift die beschriebenen fünf Charakteristika auf und führt sie zusammen; ergänzt durch weitere Komponenten ergibt sich der erste Versuch einer umfassenden Definition des Big-Data-Ökosystems: Definition 5: „Big-Data Technologien zielen darauf ab High-Volume, High-Velocity, High-Variety Daten zu verwerten, um den Wert (Value) der Daten zu extrahieren und die High-Veracity der Original Daten sicherzustellen. Der Erhalt von Informationen mit der Zielsetzung der Kosteneffektivität, innovativer Datenformen und Informationsverarbeitung (Analytics) für verbesserten Insight, einer fundierten Entscheidungsgrundlage und Prozesskontrolle soll ermöglicht werden. Diese Anforderungen sollen erfüllt werden durch neue Datenmodelle (diese Datenmodelle unterstützen alle Datenzustände und Stadien während des Datenlebenszyklus) und neue Infrastrukturservices und Tools, die die Verwertung von Daten aus einer Variation von Datenquellen ermöglichen sowie Daten in verschiedenen Variationen für unterschiedliche Datensätze, Endverbraucher und Devices bereitstellt“ (Demchenko Y., Laat C. & Membrey P. 2014, 2). Diese Definition dient als Grundlage für diese Arbeit. Zunächst sollen die beschriebenen Datencharakteristika näher beleuchtet werden. Für den Stakeholder, beispielsweise den IT-Architekten wie im Kapitel 3.1 Software-Architekturen skizziert, ist die Kenntnis über die Datencharakteristika grundlegend für die weitere Beschreibung der spezifischen Anforderungen. Die Anforderungen können nach den 5-V klassifiziert werden: Volume (= große Datenmengen im Terabyte- bis Petabyte-Bereich): Das Big-Data Volume wirkt sich auf die Speicherung und Auswertung von Data-In-Rest aus. Große Datenmengen müssen verwertet werden können. Hier werden Daten anhand von Größe, Skala, Menge und Dimension (beispielsweise Terabyte) spezifiziert, Skalierbarkeit und Robustheit muss gegeben sein, um die Verarbeitung von großen Datenmengen zu gewährleisten. (Dorschel J. 2015,264) Velocity (=Analyse von Streaming-Daten in Echtzeit oder Nahezu-Echtzeit) : Die Verarbeitung großer Datenströme (Data-In-Motion) muss gewährleistet sein, 33 Bachelor Thesis Corinna Ludwig © CORE 2016 73 die Reaktion auf Ereignisse in Datenströmen sollte in Echt-Zeit erfolgen. (Dorschel J. 2015,264) Variety (=Daten liegen in verschiedenen Formaten vor): Verschiedene Formate, beispielsweise Texte, Bilder und Videos- und Datenquellen, müssen unterstützt werden, Data-In-Rest können strukturiert, unstrukturiert, semi-strukturiert oder gemischt vorliegen; das bedeutet, Schemalosigkeit muss unterstützt werden. Für die spezifischen Daten muss es weiterhin möglich sein verschiedene Schemata zu definieren, Metadaten müssen beliebig änderbar sein. (Dorschel J. 2015,264) Veracity (= Richtigkeit von naturgemäß unvorhersehbaren Daten): Für Konsistenz muss eine Metadatenintegration für unterschiedliche Datenquellen möglich sein, Metadaten für unstrukturierte Daten stehen zur Verfügung, Datenqualität als Komponente muss berücksichtigt werden, das Ursprungsformat mit der Möglichkeit den Datenursprung identifizieren zu können, muss vorliegen. (Dorschel J. 2015,264) Value (= Wert für das Unternehmen): In der Dimension Value wird der Mehrwert beschrieben, den Big-Data durch die Verwendung der Daten in einem Prozess, einer Aktivität oder prädiktiver Analysis bieten kann. (Dorschel J. 2015,264) 3.2.5 Big-Data-Engineering Der Fokus auf Systemerneuerungen auf Grund von veränderten Datencharakteristika lässt sich im Begriff Big-Data Engineering zusammenfassen. Definition: „Big-Data Engineering beinhaltet fortgeschrittene Techniken, die voneinander unabhängige Bausteine verwenden, um skalierbare Systeme zu bauen, wenn die Charakteristika der Datensätze neue Architekturen für effiziente Speicherung, Handhabung und Analyse erfordern“ (NIST 2015, 10). Im nachfolgenden sollen einige dieser Big-Data Bausteine angeführt werden, die im Zuge des Big-Data Paradigma emergieren und grundlegend sind für datengetriebene Architekturentscheidungen. Hierzu wird zunächst der Datenlebenszyklus nach NIST vorgestellt. 3.2.6 Datenlebenszyklus Der Datenlebensyklus beschreibt eine Reihe von Prozessen innerhalb einer Anwendung, die Rohdaten in tatsächliches Wissen transformieren. Daten werden sukzessive angereichert und abstrahiert im Verarbeitungsprozess von Quell- zu Zielsystem (NIST 2015, 16). 34 Bachelor Thesis Corinna Ludwig © CORE 2016 73 NIST kategorisiert den End-to-End Datenlebenszyklus in die folgenden vier Stadien: Collection (Sammlung der Daten und Speicherung der Rohdaten), Preparation (Prozesse zur Verarbeitung von Rohdaten zu organisierten Informationen), Analysis (Techniken zur Synthese von Wissen aus den Informationen) und Action (Prozesse zur Generierung von tatsächlichem Wert aus dem synthetisierten Wissen für das Unternehmen). Festzuhalten ist, dass der Datenlebenszyklus im Mittelpunkt einer Big-Data-Lösung steht und im Big-Data-Engineering zusammen mit dem Wissen über das Datenmodell als Basis für die Auswahl der Schichten und Bausteine einer Big-Data-Lösung verwendet (NIST 2015, 16). 3.2.7 Schichten und Bausteine einer Big-Data-Lösung Die Vielfalt an Datentypen und somit Big-Data- Einsatzszenarien erfordert im Big-Data Engineering die Kombination verschiedener Bausteine auf unterschiedlichen Schichten, um so ausgehend von einer Referenzarchitektur eine Big-Data-Lösung zu beschreiben. Schichten beschreiben, wie im Kapitel 3.1 Software-Architekturen gezeigt, einen bestimmten Architektur-Stil der aus der Architektur-Perspektive „Module“ betrachtet wird. Nach BITKOM ist der „Zweck jeder BigData-Lösung, Daten in entscheidungsrelevante Informationen umzuwandeln“ (BITKOM 2014, 26). BITKOM beschreibt verschiedene Bausteine auf 6 Schichten, wie in der Grafik erkennbar. Vier Schichten - Daten-Haltung, Datenzugriff, Analytische Verarbeitung und Visualisierung markieren den „Weg von den Rohdaten hinzu geschäftsrelevanten Erkenntnissen“. Die Schichten Datenintegration und Daten-Governance sowie Sicherheit unterstützen die Einbettung in den Unternehmenskontext (BITKOM 2014, 26). Die folgende Grafik stellt die Interdependenz zwischen Datenlebenszyklus und Schichten sowie Bausteinen einer Big-Data-Lösung dar. Es ist anzumerken, dass die Schichten in der Praxis zum Teil nicht trennscharf sind, beispielsweise können Streaming-Bausteine auch für die Daten-Integration verwendet werden. 35 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Abbildung 4: Schichten und Bausteine einer Big-Data-Lösung (Quelle: eigene Darstellung in Anlehnung an BITKOM 2014,26) 3.2.8 Big-Data-Referenzarchitekturen Wie bereits im letzten Kapitel gezeigt, war der Ansatz vor Big-Data schema-getrieben und basierte zum größten Teil auf relationalen Modellen. Bisherige Architekturen sahen vor, dass Daten der Funktion folgen. Der Big-Data-Ansatz hingegen sieht vor, dass die Funktion den Daten folgt. Funktionen werden verteilt (IBM 2015, 5). Im folgenden Kapitel sollen allgemeine Verteilte Systeme definiert werden und ihre konkreten Referenzausprägungen als Lambda-Architektur und Kappa-Architektur vorgestellt werden. Verteilte Systeme Big-Data-Anwendungen werden als verteilte Systeme konzipiert, so können Verarbeitungskapazitäten entsprechend angepasst werden. Definition: „Verteilung bedeutet unter anderem, dass Daten mittels Replikaten redundant angelegt werden, einerseits zwecks Sicherung und Verfügbarkeit, wenn ein Daten-Knoten ausfällt, andererseits um schnelle, lokale Zugriffe für verteilte Prozesse zu ermöglichen“ (BITKOM 2014, 30). Für verteilte Systeme gilt das so genannte CAP-Theorem. Die Idee des CAP -Theorems wurde erstmalig durch Eric Brewer E. beschrieben (Brewer E. 2000, 4) und von Nancy Lynch und Seth Gilbert bewiesen (Gilbert, S. & Lynch, N. 2002, 1). Nach Brewer E. kann ein verteiltes System maximal zwei der gewünschten Eigenschaften: Konsistenz, Verfügbarkeit und Toleranz zu einem hohen Grad erfüllen (Brewer E. 2000, 4). Konsistenz (C) bedeutet, dass es immer nur eine Single Up-To-Date Kopie von Daten gibt, Replikate demnach identisch sind, 36 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Verfügbarkeit (A) heißt, dass Anfragen an das System stets beantwortet werden können, Partitionstoleranz (P) beschreibt die Ausfalltoleranz eines Systems, bei Verlust einer Partition des Netzes arbeitet das System weiter. Ziel ist es, die Anforderungen an die Eigenschaften so abzuwägen, dass eine bestmögliche Lösung für den jeweiligen Anwendungsfall gefunden werden kann. Bei traditionellen Datenbanken beispielweise liegt die Einordnung bei CA, bei NoSQL-Datenbanken bei AP oder CP (Brewer E. 2012, 1). Ein Big-Data-System muss partitionstolerant sein, demnach ist perfekte Verfügbarkeit bei gleichzeitiger Konsistenz ausgeschlossen. Engpässe sollen durch horizontale Skalierung ausgeglichen werden. Skalierbarkeit beschreibt einen wichtigen Grundsatz im Kontext von Big-Data. Skalierbarkeit beschreibt die Eigenschaft eines Systems, den steigenden Ansprüchen an Leistungsfähigkeit gerecht werden zu können. Es gibt zwei verschiedene Formen von Skalierbarkeit: Vertikale und Horizontale Skalierbarkeit (NIST 2015, 10). Vertikale Skalierbarkeit beschreibt das Hinzufügen von physische Ressourcen, beispielsweise CPU und Komponenten innerhalb einer logischen Einheit. Unter horizontaler Skalierbarkeit versteht man die Integration mehrerer logischer Ressourcen in einem alleinig fungierenden System, beispielsweise werden die Ressourcen eines physischen Servers auf verschiedene Systeme - virtuelle Maschinen - verteilt und können additiv skaliert werden (Wehrmaker T. 2011, 1). Eine Big-Data-Architektur muss skalierbar sein, damit für die Erfüllung der Anforderungen benötigte Leistung und Kosteneffizienz gewährleistet werden können (NIST 2015, 10). Big-Data-Architekturansätze haben sich im Zeitverlauf gewandelt. Zunächst wurde auf reine Batch-Verarbeitung gesetzt, Verarbeitung von Data-In-Rest sowie skalierbaren Lösungen und Volume im Fokus. Anschließend gab es verschiedene Lösungen zu reiner Real-Time-Verarbeitung, bei der Data-In-Motion verarbeitet wurden und geringe Latenzzeiten sowie Velocity im Fokus standen (Marcous D. 2015, 5). Marz reduziert die im Kapitel 3.1 Software-Architekturen beschriebenen Qualitätsmerkmale und charakterisiert die Anforderungen an eine Big-Data-Lösung wie folgt: Robustheit und Fehlertoleranz, Niedrige Latenzzeiten bei Lesevorgängen und Updates, Skalierbarkeit, Generalisierung, Erweiterbarkeit, Ad hoc Queries, Minimale Wartbarkeit und Debug-Möglichkeiten. (Marz N. & Warren J. 2015, 7-9) Aus den vielfältigen Charakteristika der Daten wurden anschließend unter der Berücksichtigung des Big-Data-Paradigmas verschiedene Architekturansätze für verschiedene Anwendungsfälle entwickelt. 37 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Diese Architekturansätze sind Referenzarchitekturen und stellen wie bereits im Kapitel 3.1 Software-Architekturen beschriebene bekannte Muster dar, die unterschiedliche Stile für Anwendungsfälle kombinieren. Die folgenden Architekturen sind nach Marcous (Data Wizard bei Google) an dieser Stelle nennenswert: Lambda-, Kappa-, iot-a-, Zeta- und Mu-Architektur (Marcous D. 2015, 15). Die Lambda-Architektur ist der einzige Architekturansatz, der in der Literatur beschrieben wird (Marz N. & Warren J. 2015). Die anderen werden auf Grund ihrer Neuheit nur in diversen Blogs von Mitarbeitern bekannter Unternehmen, beispielsweise Google, LinkedIn, Twitter, erklärt. Die hier beschriebenen Erkenntnisse über Architekturansätze im Big-Data-Umfeld sind daher im Zeitverlauf zu überprüfen. Da die Lambda-Architektur in der Literatur beschrieben wird und die Kappa-Architektur eine Simplifizierung darstellt, sollen in dieser Arbeit diese beiden Architekturen vorgestellt werden. Lambda-Architektur Die Lambda-Architektur stellt einen, wie im Kapitel über Software-Architektur beschrieben, Architekturstil dar. Der Architekturansatz wurde von Nathan Marz - Mitentwickler von Apache Storm (verteiltes Streaming System) - beschrieben. Das Muster ist konzipiert für Applikationen bei denen die Datenerhebung zeitverzögert stattfindet und Verfügbarkeit für Online-Auswertungen gegeben sein muss. Die grundlegende Idee der Lambda Architektur ist, dass jede Schicht des BigData Systems eine Anzahl an Eigenschaften erfüllt: A. Dateneingang (Data Ingestion): Anfänglich eingehende Daten aus unterschiedlichen Quellen werden aufgenommen und dem Batch Layer und/oder dem Speed Layer zur Verfügung gestellt (AltusInsight 2015). B. Dauerhafte Speicherung und Langzeit-Auswertung (Batch Layer): Die Batch-Verarbeitung ist zuständig für die dauerhafte Speicherung in strukturierter Form (normalisiert in Tabellen) und Langzeitauswertungen über den gesamten Bestand an Data-In-Rest und aktualisiert kontinuierlich die Batch-Sicht des Serving-Layer. Batch-Sichten stellen das Ergebnis der berechneten Daten dar- die Informationen. (Marz N. & Warren J. 2015, 83) C. Echtzeit-Analyse (Speed Layer) Bei der Speed-Verarbeitung werden eingehende Data-In-Motion bearbeitet und in Echt-Zeit ausgewertet. Die Informationslücke der Batch-Verarbeitung durch hohe Latenzzeiten wird an dieser Stelle ausgeglichen, indem fehlende Datensätze aus der Speed-Verarbeitung im Serving-Layer 38 Bachelor Thesis Corinna Ludwig © CORE 2016 73 abgebildet werden können. Nach der Bearbeitungszeit des Batch-Layers werden die temporär gespeicherten Sichten des Speed Layers gelöscht. (Marz N. & Warren J. 2015, 18) D. Indizierung der Datensätze für Analyseabfragen Der Serving-Layer dient als gedankliche Schnittstelle für die Beantwortung von Query-Anfragen und der Bereitstellung der Ergebnisse aus Kalkulationen. Konkret werden die Datensätze aus Batch-Sichten indiziert, um ad Hoc Queries zu ermöglichen.(Kiran u.a. 2015) Hier werden die Daten unstrukturiert gespeichert (Marz N. & Warren J. 2015). Eingabe der Analyseaufgaben (Query) (Marz N. & Warren J. 2015, 289) Hier können Anfragen auf die aggregierten Daten (=Cluster) durchgeführt werden. Die Schnittstelle zwischen Cluster und Anwender stellt das Query dar. (AltusInsight 2015). In der Abbildung 5 werden die beschriebenen Zusammenhänge zwischen den verschiedenen Schichten einmal graphisch dargestellt: Abbildung 5: Lambda-Architektur (Quelle: eigene Darstellung in Anlehnung an Marz und Warren 2015, 42 Eine grundlegende Eigenschaft von der Lambda-Architektur ist die „Complexity Isolation“. Die Komplexität wird in der Schicht abgebildet, dessen Ergebnisse nur temporär sind. Sobald Daten im Batch-Layer prozessiert worden sind, können die Ergebnisse der Echt-Zeit-Sicht verworfen werden. Das Master Dataset ist der „Source-Of-Truth“, Fehler in der Batch-Sicht werden durch das Master Dataset überschrieben. Nach Marz führt die Batch-Verarbeitung die exakte Berechnung durch und der im Speed-Layer verwandte Algorithmus ist approximativ (Marz N. & Warren J. 2015, 20). 39 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Die Lambda-Architektur kann demnach in drei Gleichungen zusammengefasst werden: Batch-Sicht Echtzeit-Sicht = Funktion (Echtzeit-Sicht, Neue Daten) und Query = = Funktion (Alle Daten), Funktion (Batch-Sicht. Echtzeit-Sicht) (Marz N. & Warren J. 2015, 15). Kappa-Architektur Die Kappa-Architektur ist wie die Lambda-Architektur ein Architekturstil. Die Kappa-Architektur wurde von Jay Kreps - Mitentwickler von Voldemort (Key-Value-Datenbank), Apache Kafka (verteiltes Messaging System) und Apache Samza (Streaming System) - entwickelt. Die Kappa-Architektur stellt eine Vereinfachung der Lambda-Architektur dar. Sie besteht aus den gleichen Schichten bis auf den Batch-Layer, da hier die Grundannahme ist, dass Daten nicht repliziert werden sollten und Echt-Zeit-Verarbeitung genauso akkurat ist wie Batch-Verarbeitung. Der Speed Layer übernimmt die Aufgaben des Batch Layers. Es werden Echtzeit-Daten verarbeitet, dann bestehende Daten durch verschiedene Streams aus Logs berechnet und schließlich aggregiert. Das heißt die beschriebenen Batch-Views werden durch den Speed-Layer bereitgestellt. (Uesugi S. 2014). Das bedeutet im Detail, dass dem Speed-Layer ein System vorgelagert wird, das die Möglichkeit bietet, den gesamten Log an Daten vorhalten zu können. Eine erneute Verarbeitung findet hier nur statt, wenn sich der Code für die Verarbeitung ändert. Diese erneute Verarbeitung wird parallel durchgeführt. Anstatt wie bei der Lambda-Architektur die jetzigen Sichten mit den Masterdaten zu überschreiben, wird für die erneute Verarbeitung bei der Architektur eine neue Instanz innerhalb des Speed-Layers gestartet. Der Zeitstempel der neu zu verarbeitenden Daten ist innerhalb des Logs beliebig selektierbar (jetzt, vor einem Tag, vor einem Jahr), die Daten werden erneut verarbeitet und in eine neue Output-Tabelle geschrieben. Die alte Output-Tabelle im Serving-Layer wird gelöscht und die neue Output-Tabelle dient als Grundlage (Kreps J. 2014). Im Ergebnis wurden durch die Industrie Referenzarchitekturen für Big-Data entwickelt. Ausgehend von allgemeinen und Marketing-getriebenen Definitionen haben wir auf Basis des abstrahierten 3V-Modells die Daten-Ebene und ihre Ausprägung in No-SQL-Modellen betrachtet. Somit wurde eine Ökosystembetrachtung (5V-Modell) möglich. Durch die Einbeziehung des Engineering-Ansatzes, des Datenlebenszyklus und einer Schichten-Analyse wurden zuletzt die Lambdaund Kappa-Referenzarchitekturen vorgestellt. Ein Raster zur Bewertung der Relevanz und Eignung von Big-Data Taxonomien für die Versicherungsbranche liegt somit vor. 40 Bachelor Thesis Corinna Ludwig © CORE 2016 73 4 Analyseinstrumente In diesem Kapitel sollen die folgenden Analyseinstrumente kurz vorgestellt werden: Das Kartesische Koordinatensystem für die Quantifizierung der Relevanz von Big-Data für Versicherungen und das Scoring-Modell für die Bewertung der Architekturen. 4.1 Das Kartesische Koordinatensystem Zweck und Absicht Die Idee des Tools basiert auf der Idee von René Descartes (1596-1650). Mit Hilfe des Tools sollen mögliche Optionen und Konsequenzen, basierend auf konditionalen Kombinationen, beispielsweise „wenn A, dann B“, ermittelt werden. Das Tool bietet die Grundlage für eine erste Strukturierung der eigenen Gedanken zu einer Ursache-Wirkungs-Beziehung. Verschiedene Aspekte und Sichtweisen sollen entdeckt werden. (Andler N. 2007, 406) Funktionen und Aufgabe Mögliche negative und positive Ergebnisse sowie Konsequenzen sollen für die Entscheidungsfindung aufgezeigt werden. Verschiedene Ergebnisse ergeben sich durch die Bedingungen und die unterschiedliche Kombination von zwei Aussagen, die in einer Ursache-Wirkungs-Beziehung zueinander stehen. (Andler N. 2007, 406) Vorgehen 1. Zwei Aspekte, die voneinander abhängen, werden definiert. Der erste Aspekt stellt die Ursache (A) und der zweite Aspekt die Auswirkung dar (B), beispielsweise Einführung von Multimedia-Technologie (A) und Konsumentenverhalten (B). 2. Für jede der vier Kombinationen wird ein positives sowie ein negatives Ergebnis beschrieben: I Wenn A eintritt, was würde mit B passieren? II Wenn A nicht passiert, was würde mit B passieren? III Wenn A eintritt, was würde nicht mit B passieren? IV Wenn A nicht eintritt, was würde nicht mit B passieren? Die Ergebnisse können in einem Kartesischen Koordinatensystem (=Matrix) visualisiert werden. (Andler N. 2007, 406) 41 Bachelor Thesis Corinna Ludwig © CORE 2016 73 4.2 Das Scoring-Modell Zweck und Absicht Bei der Nutzwertanalyse oder auch Scoring-Modell genannt sollen messbare und vergleichbare quantitative Ergebnisse erzielt werden. Verschiedene Optionen werden hier abgewogen. Das Tool findet Anwendung bei komplexen Entscheidungen sowie schwer handhabbaren Problemen. Es soll als erste Bewertungsgrundlage dienen und den Entscheidungsprozess unterstützen. (Andler N. 2007, 407) Funktionen und Aufgaben Verschiedene Kriterien werden gewichtet und bewertet. Das Ergebnis der gewichteten Kalkulation entspricht einem „Gewinner nach Punkten“. (Andler N. 2007, 407) Vorgehen Alle relevanten Kriterien werden identifiziert. 1. Evaluierungskriterien können in Haupt- und Unterkategorien unterteilt werden 2. Jedem Kriterium wird eine Gewichtung zugewiesen. Maximal 100 Prozent in Prozentanteilen oder numerischen Werten können vergeben werden. Bei Zahlen wird eine Höchstzahl vergeben. 3. Prüfung, ob die Vergabe der Gewichtung auch der Wichtigkeit der Anforderung entspricht. 4. Für jedes Kriterium wird für jede Option eine Punktzahl vergeben. Die höchstmöglich zu vergebende Punktzahl wird vorher festgelegt. 5. Die Gewichtungen und Punktzahlen werden multipliziert und die endgültige Punktzahl für jedes Kriterium ermittelt. 6. Die endgültigen Punktzahlen aller Kriterien aufsummiert ergeben den endgültigen Punktestand für die Option. Die Ergebnisse werden tabellarisch festgehalten. (Andler N. 2007, 407) 42 Bachelor Thesis Corinna Ludwig © CORE 2016 73 5 Big-Data-Architekturen im Kontext Versicherungen Dieses Kapitel baut auf der Darstellung der Charakteristiken und Herausforderungen der Versicherungsindustrie in Bezug auf das Datenmanagement im Kapitel 2 auf. Kernpunkte sind die sich ändernden Kundenbedürfnisse und -verhalten im digitalen Zeitalter. Der gemeinsame Nenner der Anwendungsfälle für die Verbesserung der Kundeneinsicht und der Adressierung der Bedürfnisse der heranwachsenden digitalen Generation ist die Analyse steigender Datenmengen. Die Analyse des Wettbewerbs zeigt, dass die Institute darüber hinaus mit Anbietern konkurrieren, die sich neue Technologien zu Nutze machen. Des Weiteren dient als Grundlage für die weitere Analyse die Betrachtung des Big-Data-Ökosystems wie im 5V-Modell beschrieben. Weitere Anforderungen werden aus dem CAP-Theorem sowie den Anforderungen an eine Big-Data-Lösung analysiert. Stellvertretend wird die Betrachtung entlang der vorgestellten Referenzarchitekturen Lambda und Kappa vorgenommen. Die Relevanz von Big-Data für Versicherungen wird zum Eingang des Kapitels erörtert (5.2). Das Modell für den Vergleich und die Bewertung hergeleitet (Kapitel 5.2). Anhand von ausgewählter Referenzarchitekturen wird das Modell erprobt, um schlussendlich Erkenntnisse und Folgerungen (Kapitel 5.3) für den Entscheidungsprozess ableiten zu können. Somit werden die eingangs gestellten Forschungsfragen beantwortet: F1: Ist der Einsatz von Big-Data für ein Versicherungsunternehmen von Relevanz? F2: Wie könnte ein Modell zur Objektivierung der Architekturentscheidung für Big-DataLösungen aussehen? F3: Welche Ergebnisse liefern der Vergleich und die Bewertung ausgewählter Architekturen mit Hilfe des Modells? 5.1 Relevanz von Big-Data bei Versicherungen Der Einsatz von Big-Data Architekturen wird grundlegend durch die Analyse der Chancen und Herausforderungen in Bezug auf die Wertschöpfung in seiner Relevanz bewertet. Die Bewertung wird durch eine Übertragung auf das kartesische Koordinatensystem erhärtet und illustriert. Es wird etabliert, dass die Chancen einer Einführung dabei signifikant die Risiken und die gegenüberstehenden Aspekte bei der Fortführung aktueller Datenmodelle überwiegen. Anwendung des Analyseinstruments Kartesisches Koordinatensystem Mit Hilfe des Tools sollen beispielhafte Argumente zu dem Thema „Big-Data- Relevanz für ein Versicherungsunternehmen“ strukturiert werden. Eine weitere Quantifizierung erfolgt im Rahmen dieser Arbeit nicht. Auf Grund der hohen Anzahl an Argumenten wurde bewusst auf eine Visualisierung verzichtet. Wie im Kapitel 4 beschrieben sollen zwei voneinander abhängige Aspekte definiert werden. Der erste Aspekt stellt die Ursache (A) und der zweite die Auswirkung dar (B). 43 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Hier sollen basierend auf den theoretischen Grundlagen die folgenden Ursache-Wirkungs-Beziehungen analysiert werden: Ursache (A) : Auswirkung (B): Wertschöpfung. Einführung einer Big-Data-Lösung und Für jede der vier Kombinationen wird nach dem eigentlichen Vorgehen ein positives sowie ein negatives Ergebnis beschrieben: I Wenn A eintritt, was würde mit B passieren? II Wenn A nicht passiert, was würde mit B passieren? III Wenn A eintritt, was würde nicht mit B passieren? IV Wenn A nicht eintritt, was würde nicht mit B passieren? An dieser Stelle soll das Vorgehen der Anwendung des Analyseinstruments modifiziert werden. Die Frage - „Ist der Einsatz von Big-Data für ein Versicherungsunternehmen von Relevanz?“impliziert die Klassifizierung von Chancen (positivem Ergebnis) und Herausforderungen (negatives Ergebnis) für die Einführung und Nicht-Einführung von Big-Data. Daher sollen lediglich die Fragen I und II betrachtet werden. Die folgenden Fragen ergeben sich daraus: I Wenn ein Versicherungsunternehmen eine Big-Data Lösung (A) einführt, I a: welche Chancen (positives Ergebnis) I b: und Herausforderungen (negatives Ergebnis) ergeben sich für die Wertschöpfung (B)? II Wenn ein Versicherungsunternehmen keine Big-Data Lösung (A) einführt, II a: welche Chancen (positives Ergebnis) II b: und Herausforderungen (negatives Ergebnis) ergeben sich für die Wertschöpfung (B)? Auf Grund der hohen Anzahl an Argumenten wurde bewusst auf eine Visualisierung verzichtet. Das Muster für eine Ursache-Wirkungs-Matrix wird an dieser Stelle somit nur in Kürze vorgestellt: Die x-Ache wird mit der Ursache (A) - Einführung einer Big-Data-Lösung - gekennzeichnet, die yAchse stellt die Wirkung auf die Wertschöpfung (B) dar. Die Chancen (positive Ergebnisse) werden in den Quadranten I a und II a für eine Einführung sowie eine Nicht-Einführung eingeordnet. Die Herausforderungen (negative Ergebnisse) können analog in den Quadranten I b und II b dargestellt werden. 44 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Abbildung 6: Big-Data Ursache-Wirkung-Matrix (Quelle: eigene Darstellung in Anlehnung an Andler N. 2007, 406) 5.1.1 Chancen und Herausforderungen der Einführung einer Big-Data-Lösung einführen Würde ein Versicherungsunternehmen eine Big-Data-Lösung einführen, … I a: Chancen (Positives Ergebnis): …so könnte ein Versicherungsunternehmen aktiv anstatt reaktiv auf Veränderungen in der Branche reagieren (Time-to-Market), …so könnte beispielsweise das Management die Nutzung von Daten für eine angemessenere Entscheidungsgrundlage nutzen, …so könnte neues Innovationspotenzial erschlossen und neue Wertschöpfung gefordert werden, …so könnten durch gezieltes Datenmanagement interne Prozesse optimiert und neue Geschäftsprozesse erschlossen werden, …so könnte die Beantwortung regulatorischer Anforderungen durch die gezielte Aufbereitung von erforderlichen Informationen erleichtert werden, …so könnte die Funktion der Datenverarbeitung/IT eine tragende Rolle bei der Unterstützung der Unternehmensbereiche einnehmen und durch umfassendere Datenanalyse die Basis für eine übergreifende Entscheidungsbasis legen, … so könnte analog zum Gesetz der großen Zahl insbesondere im Risikobereich Risiken bei der Antragsprüfung besser eingeschätzt und Schadensquoten reduziert werden, 45 Bachelor Thesis Corinna Ludwig © CORE 2016 73 … so könnten speziell im Bereich Produktentwicklung individuelle, innovative auf den Kunden angepasste Produkte konzipiert werden, …so könnte beispielsweise die Ausrichtung des Marketings und Vertriebs - auf Basis von Datenanalysen - individuell auf die veränderten Kundenbedürfnisse und das Kundenverhalten ausgerichtet werden. I b: Herausforderungen (Negatives Ergebnis): …so könnte dies dazu führen, dass die Organisation die Einführung nicht tragen kann, die für Big-Data notwendigen Entwicklungen der Flexibilisierung der Organisation (beispielsweise die Verzahnung der IT) zurückbleiben und so die Chancen durch Big-Data nicht ausreichend genutzt werden können, …so könnten Mitarbeiter nicht genügend qualifiziert sein, um Big-Data gewinnbringend für die Organisation zu nutzen, …so könnten regulatorische Anforderungen den Einsatz von Big-Data zum besseren Verständnis des Kunden zukünftig einschränkt werden. 5.1.2 Chancen und Herausforderungen bei der Weiterarbeit ohne eine BigData-Lösung II. Würde ein Versicherungsunternehmen keine Big-Data-Lösung einführen, … II a: Chancen (Positives Ergebnis): …so könnten Aufwände für Qualifizierung der Mitarbeiter und Flexibilisierung der Organisation eingespart werden, …so könnten Aufwände für die Erneuerung und Integration der Systemlandschaft und für die Verzahnung der IT mit anderen Unternehmensbereichen reduziert werden, …so könnten traditionelle Versicherungen den Markt weiterhin beobachten und erst reagieren, wenn absoluter Handlungsbedarf besteht. II b: Herausforderungen (Negatives Ergebnis): …so könnte ein Versicherungsunternehmen nur reaktiv auf Veränderungen in der Branche - wie beispielsweise die Fragmentierung der Wertschöpfungskette durch InsurTechs - reagieren, …so könnte die strategische Entscheidungsgrundlage für das Management wichtige Sichten ausschließen, …so könnte die Innovationsfähigkeit gefährdet sein, …so könnte eine angedachte Prozessoptimierung zur Unterstützung der Wertschöpfungskette nur begrenzt möglich sein, …so müssten möglicherweise hohe Aufwände für die Beantwortung regulatorischer Anforderungen durch die gezielte Aufbereitung von erforderlichen Informationen erbracht werden, 46 Bachelor Thesis Corinna Ludwig © CORE 2016 73 …so könnte sich bei der Umsetzung einer Lösung zu einem späteren Zeitpunkt der Integrationsaufwand für neue Lösungen in die teilweise veraltete IT-Systemlandschaft erhöhen, …so könnten die Risikoeinschätzung, Produktentwicklung, der Vertrieb und das Marketing nur hinreichend auf die individuellen Kundenbedürfnisse ausgerichtet werden, 5.1.3 …so könnte das Wechselverhalten von Kunden steigen. Erkenntnisse und Folgerungen Im diesem Kapitel wird dargelegt, inwiefern die Forschungsfrage mit dem vorgelegten Modell beantwortet werden kann. Grenzen im Rahmen dieser theoretischen Untersuchung werden aufgezeigt und Ansätze zu ihrer Überwindung in der Praxis vorgeschlagen. In Kapitel 5.1 konnte die folgende Forschungsfrage beantwortet werden: F1: Ist der Einsatz von Big-Data für ein Versicherungsunternehmen von Relevanz? Für die Beantwortung der Forschungsfragen wurden Chancen sowie Herausforderungen bei der Einführung sowie einer Weiterarbeit mit bisherigen Lösungen identifiziert. Bereits im Kapitel 2 „Theoretische Grundlagen: Versicherungen“ wurde die Wichtigkeit der Datenverarbeitung für die Risikotransformation und die Herausforderungen durch den Eintritt neuer technologiebewusster Wettbewerber am Markt sowie der wandelnden Bedürfnisse der heranwachsenden digitalen Generation etabliert. Diese Erkenntnisse sowie die im Kapitel 3.2. „Big Data Technologien“ beschriebenen Chancen durch Big-Data, wurden auf Basis des Analyseinstruments „Kartesisches Koordinatensystem“ aus Kapitel 4.1 strukturiert. Die Einordnung erfolgte entlang der Identifikation von möglichen Chancen und Herausforderungen in Bezug auf die Wertschöpfung bei einer Einführung oder Nicht-Einführung einer Big-Data-Lösung. Es lässt sich feststellen, dass die umfassenden Chancen bei der Einführung einer Big-Data-Lösung die einhergehenden Herausforderungen deutlich überwiegen. Gleichzeitig kann die Fortführung bestehender Modelle keine deutlichen Vorteile generieren. Die Nutzung der Big-Data-Lösungen ist zu bevorzugen und ist somit von Relevanz für Versicherungen. An dieser Stelle sollen die Grenzen der theoretischen Betrachtung aufgezeigt werden. Das Aufzeigen der Ursache-Wirkungsbeziehung basierte auf einem Ausschnitt der insgesamt verfügbaren Informationen in der Literatur. Das hier verwendetet kartesische Koordinatensystem bietet die Grundlage für eine Strukturierung der eigenen Gedanken zu einer Ursache-Wirkungs-Beziehung. Die Argumente wurden nicht weiter quantifiziert. Sichtweisen wie Stärken- und Schwächen des Unternehmens oder andere Wirkungsmechanismen wurden nicht betrachtet. Für die Betrachtung von Indizien für die Relevanz von Big-Data für Versicherungen war das Tool an dieser Stelle zweckdienlich. In der Praxis könnten zusätzlich messbare Kennzahlen und Expertenmeinungen herangezogen werden. Die Analyse sollte darüber hinaus quantifiziert werden können. 47 Bachelor Thesis Corinna Ludwig © CORE 2016 73 5.2 Big-Data-Architekturentscheidung Die Relevanz von Big-Data-Architekturen wurde im Kapitel 5.1 gezeigt. In der Folge soll ein Modell hergeleitet werden. Dieses Modell sieht eine Taxonomie für den Vergleich und eine Bewertungsmethode für die Bewertung von Architekturen zur Objektivierung der Entscheidungsfindung vor. Hierzu wird zunächst die Taxonomie beschrieben (Kapitel 5.2.1.). Die Taxonomie stellt ein Klassifikationsschema dar, um die Architekturen anhand von definierten Kriterien vergleichen zu können. Zu diesem Zweck werden die technischen Grundlagen unter Nutzung von objektivierbaren Kriterien zusammengeführt. Diese Taxonomie dient dem generischen Vergleich unter Berücksichtigung allgemeingültiger Anforderungen an eine Big-Data-Lösung und ist unabhängig vom konkreten Anwendungsfall. Im nächsten Schritt soll diese Taxonomie am Beispiel von den vorgestellten Referenzarchitekturen Lambda und Kappa erprobt werden (Kapitel 5.2.2.). Im Folgenden wird die Bewertungsmethode anhand des Scoring-Modells aus dem Kapitel 4.2. die konkrete Bewertung von Referenzarchitekturen hergeleitet (Kapitel 5.2.3.) und im nächsten Schritt auf den Vergleich der Architekturen angewandt (Kapitel 5.2.4.). Anschließen sollen die Erkenntnisse und Folgerungen zusammengefasst werden (Kapitel 5.2.5.). Ein konkreter Anwendungsfall in einer Versicherung wird hier nicht betrachtet. Diese Betrachtung wird im Entscheidungsprozess der zunächst generischen Betrachtung nachgelagert und bedarf der Kenntnis individueller Anforderungen. Hier soll zunächst die Abgrenzung zu einer Architekturevaluationsmethode wie im Kapitel 3.1. „Software-Architekturen“ beschrieben kurz skizziert werden. Die hier zu entwickelnde Taxonomie für den Vergleich und die Bewertungsmethode für die Bewertung von Referenzarchitekturen ist vorgelagert zu Architekturevaluationsmethoden. Hier werden Referenzarchitekturen im Big-DataKontext im Zuge einer ersten Bewertung vergleichbar gemacht. Diese Bewertung bildet den ersten Meilenstein für eine Architekturentscheidung. Daraufhin werden wie in der Abbildung 2 (Software-Architektur-Lebenszyklus) im Kapitel 3.1.1. beschrieben, Anforderungen und Einflussfaktoren, Szenarien und Risiken weiter individuell für das Unternehmen und den Anwendungsfall spezifiziert, um dann die Architektur zu dokumentieren. Der Entwurf kann dann durch bestehende Architekturevaluationsmethoden - wie beispielsweise ATAM - geprüft werden, um letztendlich eine Software-Architektur umsetzen zu können. 5.2.1 Klassifikation und Herleitung der Kriterien für die Taxonomie Im Kapitel 5.1. wurde die Relevanz von Big-Data bei Versicherungen quantifiziert. Im weiteren Entscheidungsfindungsprozess ist die Objektivierung der Architekturentscheidung für eine BigData-Lösung der nächste Schritt, um für die Stakeholder die weitere Architekturevaluation vorzubereiten. Hierzu wird eine Taxonomie entwickelt. Diese dient als Klassifikationsschema für BigData-Architekturstile. Zunächst werden Kriterien hergeleitet, diese werden klassifiziert, zusammengefasst zu Obergruppen, um dann die wesentlichen Fragen für den Vergleich abzuleiten. 48 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Für die Taxonomiebeschreibung werden acht Kriterien entwickelt und detailliert: Kriterium 1: Kurzbeschreibung, Kriterium 2: Hauptziel, Kriterium 3: Annahmen, Kriterium 4: Paradigmen, Kriterium 5. Anforderungen, Kriterium 6: Risiken, Kriterium 7: Reifegrad und Kriterium 8: Referenzen. Die Kriterien 1-4 sind indikativer Natur, Kriterien 6-8 können objektiviert werden. Zur Ausgestaltung der vorgeschlagenen Kriterien werden in der Folge Subkriterien abgebildet, die beim späteren Architekturvergleich zu überprüfen sind. Es wird jeweils auf die theoretischen Grundlagen hingewiesen, falls diese als Grundlage für die Beschreibung des Kriteriums gedient haben. Kriterium 1: Kurzbeschreibung Kriterium Name Beschreibung Kurzbeschreibung Die Grundzüge der Architektur sollen in 4-5 Sätzen beschrieben werden. Subkriterium - - Tabelle 3: Kriterium Kurzbeschreibung (eigene Darstellung) Kriterium 2: Hauptziel Kriterium Name Beschreibung Hauptziel Referenzarchitekturen können für verschiedene Zielsetzungen konzipiert werden. Keine Architektur kann alle Ziele gleichermaßen erfüllen. Hier wird das Hauptziel identifiziert. Subkriterium - - Tabelle 4: Kriterium Hauptziel (eigene Darstellung) 49 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Kriterium 3: Annahmen Kriterium Name Beschreibung Annahmen Für die Konzeption einer Referenzarchitektur werden bestimmte Grundannahmen getroffen. Diese sollen hier beschrieben. Subkriterium - - Tabelle 5: Kriterium Annahmen (eigene Darstellung) Dieses Kriterium basiert auf den skizzierten theoretischen Grundlagen über „Schichten und Bausteine einer Big-Data-Lösung“ im Kapitel 3.2.7. Die einzelnen Schichten werden hier als Paradigmen geführt, da sie Grundsatzentscheidungen für die Architektur darstellen. Kriterium 4: Paradigmen Kriterium Name Beschreibung Paradigmen Einer Referenzarchitektur werden verschiedene Paradigmen zu Grunde gelegt. Diese sollen an dieser Stelle identifiziert werden, um beispielsweise zu einem späteren Zeitpunkt des Entscheidungsfindungsprozesses die zielgerichtete Technologieauswahl treffen zu können. Subkriterium Datenzugriff (Prozes- An dieser Stelle soll der in der Architektur verwendete sierung) Baustein für den Datenzugriff, dem Lesen von Informationen, identifiziert werden. Die Bausteine sind die folgenden: Batch Processing, Streaming Processing, Search und Discovery sowie Querys. Datenhaltung Mit der Abfrage dieses Subkriteriums soll die Speicherung der Daten beschrieben werden. Der zugehörige Baustein wird benannt. Die Bausteine sind die folgenden: Distributed File System, No-SQL-Datenbanken, Relationale Datenbanken und In-Memory-Datenbanken. Analytische Verarbei- Welcher Baustein für die analytische Verarbeitung tung und somit für die Gewinnung von Erkenntnissen aus der Datenanalyse verwendet wird, soll an dieser Stelle identifiziert werden. Die folgenden Bausteine zählen zur analytischen Verarbeitung: Audio/Video, Geospatial, Data Mining, Predictive, Web, Machine Learning, Test/Semantic und Reporting. 50 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Datenintegration An dieser Stelle werden die Bausteine für die Datenintegration, dem Zusammenführen von Informationen, aufgezählt. Die Bausteine sind die folgenden: DatenKonnektivität und Daten-Ingestion (ELT, ETL). Tabelle 6: Kriterium Paradigmen (eigene Darstellung) An dieser Stelle sollen die Bausteine für die einzelnen Paradigmen näher skizziert sowie das jeweilige Merkmal beschrieben werden. Der jeweilige Zweck, für den der Baustein optimiert worden ist, wird klassifiziert. Datenzugriff Name (des Bausteins) Erläuterung Batch Processing Merkmal: Stapelverarbeitung (MapReduce) Optimiert für: Parallele Verarbeitung von Daten Beschreibung: Die Verarbeitung der Daten in einer Eingabedatei erfolgt automatisch, sequentiell und vollständig ohne Eingriffe des Benutzers (BITKOM 2014, 25). Die eingehenden Daten werden sequentiell verarbeitet, neu eingehende Daten können parallel verwertet werden. MapReduce ist ein im Umfeld von Hadoop geprägter Begriff und beschreibt die Verteilung der Eingabedateien in einer Phase „Map“ und die Aggregation zu einem Ergebnis in der Phase „Reduce“. Die Vorgänge in den jeweiligen Phasen laufen nach dem Batch-Prinzip. (BITKOM 2014, 49). Streaming Processing Merkmal: Echtzeitverarbeitung and CEP Optimiert für: Streaming wird unter anderem im Complex Event Processing genutzt, um Echtzeit Ereignisse zu verarbeiten und zu analysieren. Beschreibung: Hier wird Data in Motion (Datenstrom) kontinuierlich verarbeitet bei gleichzeitiger kontinuierlicher Bereitstellung von Ergebnisdaten. (BITKOM 2014, 25). Search und Discovery Merkmal: Verarbeitung unstrukturierter Daten Optimiert für: Erfassung von Zusammenhängen von unstrukturierten Daten. Beschreibung: Informationen sollen in unstrukturierten Daten gesucht und entdeckt werden, zudem werden verwandte Antworten ermittelt, um Zusammenhänge herzustellen. Algorithmen führen Matching von Textbausteinen durch und Indizes helfen bei der Suche. (BITKOM 2014, 25) 51 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Datenhaltungsschicht Name (des Bausteins) Erläuterung Distributed File System Merkmal: Verteilte Datenspeicherung (NIST 2015, 14) Optimiert für: Serielle Verarbeitung von großen Datenmengen Beschreibung: Das Konzept eines solchen Distributed File System, oder auch verteiltes Dateisystem genannt, beschreibt die Verteilung von Datensätzen innerhalb eines Netzwerks (engl. Nodes) von Clustern und erlaubt so Datenspeicherung auf mehreren Fileservern. (NIST 2015, 14). Des Weiteren ist die verteilte Datenspeicherung durch hohe Verfügbarkeit gekennzeichnet und erfüllt die Anforderungen von Skalierbarkeit und Reliabilität durch Replikation (BITKOM 2014, 26) No-SQL Datenbanken Merkmal: Datenspeicherung mit flexiblen Schemata. (BITKOM 2014,26) Optimiert für: Speicherung von unstrukturierten und vernetzten Daten, beispielsweise für Anwendungsszenarien wie Social Media oder Predictive Analytics (BITKOM 2014, 26). Beschreibung: NoSQL steht für Not-Only SQL und beschreibt die Ergänzung von relationalen Modellen durch die Verwendung von flexiblen Schemata. Der Begriff ist nicht klar in der Literatur definiert. Es zählen hierzu alle Datenbanken, die nicht hundert Prozent einer relationalen Datenbank zuzuordnen sind, relationale Beziehungen können durch Indizes dennoch nachgebildet werden. Daten können im Format von Dokumenten, Graphen, Key-Value-Paaren oder Spalten gespeichert werden. (BITKOM 2014, 26) Relationale Datenban- Merkmal: Datenspeicherung mit festen Schemata (NIST 2015, 12) ken Optimiert für: Speicherung von strukturierten Daten in feste Schemata (NIST 2015, 12). Eine Klasse der relationalen Datenbanken, die analytischen Datenbanken, sind für das Einsatzszenario OLAP optimiert. Transaktionale Datenbanken wiederum für OLTP. Beschreibung: Relationale Datenbanken basieren auf einem tabellenbasierten relationalen Datenbankmodell und sind nicht neu, sie werden in Big-Data-Lösungen oftmals zusammen mit No-SQL Datenbanken oder Distributed File Systems eingesetzt. 52 Bachelor Thesis Corinna Ludwig © CORE 2016 73 In-Memory- Merkmal: Speicherung der Daten im Hauptspeicher (BITKOM Datenbank 2014, 47) Optimiert für: Schneller Zugriff auf Informationen in Echtzeit, die nicht persistiert werden müssen. Einsatzbeispiele bestehen im Bereich Predictive Modeling und Echtzeit-Daten-Zugriff (BITKOM 2014, 47). Beschreibung: Daten bis zu mehreren Terabyte werden in dem Hauptspeicher (RAM/Memory) von Plattenspeichern verlagert. InMemory- Datenbanken sind mit dem Fall von Speicherkosten interessant geworden, sie werden oft zusammen mit anderen Datenbanken eingesetzt, da die Speicherkapazitäten begrenzt sind. (BITKOM 2014, 47) Analytische Verarbeitung Name des Bausteins Audio/Video Mining Erläuterung Merkmal: Textanalyse Optimiert für: Analyse multimedialer Inhalte über Konvertierung in Textdateien Beschreibung: Die Text-Informationen von multimedialen Inhalten werden zunächst extrahiert mit Hilfe von Transkriptios-Algorithmen, dann werden linguistische und semantische Verfahren genutzt, um Zusammenhänge herstellen zu können (BITKOM 2014, 61). Geospatial Analytics Merkmal: Statistische und mathematische Analyse Optimiert für: Analyse geografischer oder räumlicher Daten Beschreibung: Unter der Hilfenahme von Global Positioning System (GPS)- Koordinaten werden geografische und Daten mit statistischen und mathematischen Verfahren analysiert. Data Mining Merkmal: Statistische Analyse Optimiert für: Analyse von großen strukturierten Datenmengen. Beschreibung: Statistische Methoden werden auf große Datenbestände angewandt, um möglichst automatisch empirische Zusammenhänge zu extrahieren. Der Begriff Data Mining umfasst verschiedene Methoden und Verfahren. Ein Teilgebiet ist Predictive Analytics für die Vorhersage von Trends und zukünftigen Geschäftsrisiken. Predictive Analytics erfolgt in drei Schritten: Descriptive (Beschreiben), Predictive (Vorhersagen) und Prescriptive (Empfehlen) (BITKOM 2014, 61). Web Analytics Merkmal: Logdateianalyse. Optimiert für: Analysen von Web-Inhalten 53 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Beschreibung: Im Zuge von Web Analytics werden die Daten gemessen, erfasst, analysiert und reported die für die Webpräsenz zu optimieren sind (BITKOM 2014, 57). Machine Learning Merkmal: Maschineller iterativer Lernprozess durch statistische und logische Analysen und Algorithmen Optimiert für: Problemlösung zentraler Fragestellungen beispielsweise bei komplexen Planungsaufgaben Beschreibung: Computerprogramme erwerben über einen maschinellen iterativen Prozess im Zuge von statistischen, logischen Analysen und Algorithmen neues Wissen, um Lösungen für Problemstellungen zu finden. Im Nachhinein wird die Aufbereitung der Informationen für die Analyse historischer Daten verwendet oder werden als Grundlage für automatische Prozesse genutzt. (BITKOM 2014, 66) Text Mining Merkmal: Linguistische und semantische Analysen Optimiert für: Textanalyse von unstrukturierten Daten Beschreibung: Extraktion von Informationen, Strukturen sowie Verknüpfungen aus unstrukturierten Datenströmen und Texten mit Hilfe von linguistischen und semantischen Verfahren (BITKOM 2014, 58). Reporting Merkmal: Analytische Aufbereitung Optimiert für: Zusammenfassung von strukturierten Daten zur visuellen Bereitstellung Beschreibung: Detailberichte von strukturierten Daten in Form von Tabellen und grafischen Elementen werden bereitgestellt. Diese Detailberichte für die Visualisierungssicht verfügbar gemacht- beispielsweise auf einem Dashboard. (BITKOM 2014, 26) Daten-Integration Name (des Bausteins) Erläuterung Datenkonnektoren Merkmal: Integration von verschiedenen Datenquellen und Bereitstellung der Daten (BITKOM 2014, 26) Optimiert für: Strukturierte Daten aus existierenden Anwendungen, beispielsweise ERP, CRM (BITKOM 2014, 89) Beschreibung: Die Zugänglichkeit der Daten aus verschiedenen System wird durch Schnittstellen (=Konnektoren) gewährleistet, beispielsweise durch Datenbanken, Anwendungen oder Middleware. Daten werden über Standardschnittstellen, beispielsweise XML, JMS Messaging Middleware, SQL, bereitgestellt. (BITKOM 2014, 26) 54 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Daten-Ingestion Merkmal: Umwandlung von Daten aus verschiedenen Quellen Optimiert für: Daten mit unterschiedlichen Eingangsformaten Beschreibung: Bei der Ingestion (Aufnahme) sollen Daten aus verschiedenen Quellen importiert werden können (BITKOM 2014, 27). Im traditionellen relationalen Modell werden die Daten nach der Preparationsphase gespeichert und nach dem „Schema-On-WriteKonzept“ verwertet. Das bedeutet: Zunächst erfolgt der Datenimport aus verschiedensten Quellen in eine Big-Data-Lösung, auch Ingestion (Aufnahme) genannt. Die Umwandlung der Daten erfolgt in drei Schritten: Extract, Transform, Load (ETL). Diese drei Schritte bezeichnen den „Prozess der Aufbereitung von Rohdaten für die nachgelagerte Speicherung dieser Daten in einer analytischen Datenbank. Rohdaten werden normalisiert und validiert“ sowie mit einem Datenbank-Schema versehen. So können die Daten in eine relationale Datenbankstruktur übertragen werden (BITKOM 2014, 27). Im Fall eines Big-Data Use-Case werden die Daten vor der Preparationsphase in ihrem rohen Zustand gespeichert. Die Prozessschritte werden umgekehrt: Extract, Load, Transform (ELT). Rohdaten werden ohne Struktur in das Speichermedium hochgeladen, zum Analysezeitpunkt werden sie transformiert. (BITKOM 2014, 27) Dieses Big-Data Konzept wird als „Schema-On-Read“ bezeichnet (NIST 2015, 6). Daten werden hochgeladen und erst dann gelesen. Die Datenstruktur bzw. das Datenschema wird in dem Moment interpretiert, in dem es gelesen wird. (Kerr R. 2013) Tabelle 7: Subkriterium Paradigmen Die Klassifizierung der einzelnen Anforderungen sollen an dieser Stelle basierend auf der Theorie „Klassifizierung der Daten für ein Datenmodell“, „Big-Data-Ökosystem: Das 5-V-Modell“ und „BigData-Referenzarchitekturen“ aus dem Kapitel 3.2.4. erfolgen. Kriterium 5: Anforderungen Kriterium Name Beschreibung Anforderungen An dieser Stelle sollen die durch die Referenzarchitektur adressierten Anforderungen identifiziert werden. Subkriterium Datenmodell-Anforde- Unter dem Punkt Datenmodell-Anforderungen wird rungen geprüft, ob bestimmte Eigenschaften der Daten innerhalb des Datenmodells der Architektur Berück- 55 Bachelor Thesis Corinna Ludwig © CORE 2016 73 sichtigung gefunden haben. Daten sollen im Rohzustand vorliegen, unveränderlich und „eternally true“ sein. High-Level- In diesem Zusammenhang soll geprüft werden, wel- Big-Data- che der Big-Data-Charakteristika erfüllt werden. Die Anforderungen Charakteristika sind Volume, Velocity, Variety und Veracity. Systemeigenschaften An dieser Stelle sollen die Eigenschaften an verteilte Systeme geprüft werden: Konsistenz (C), Verfügbarkeit (A), Partitionstoleranz (P) Qualitätsmerkmale Mit Hilfe des Kriteriums Qualitätsmerkmale werden hier diejenigen Anforderungen geprüft, die eine BigData-Lösung erfüllen sollte: Robustheit, Niedrige Latenzzeiten, Skalierbarkeit, Generalisierung, Erweiterbarkeit, Ad hoc Queries, Minimale Wartbarkeit und Debug-Möglichkeiten. Tabelle 8: Kriterium Anforderungen (eigene Darstellung) Die Detaillierung der Subkriterien erfolgt in der nachfolgenden Tabelle: Datenmodell-Anforderungen Name (des Bausteins) Erläuterung Daten sollen im Rohzustand Daten werden möglichst unbearbeitet gespeichert, das heißt, vorliegen sie liegen unter anderem unstrukturiert vor. So wird gewährleistet, dass Erkenntnisse aus historischen Daten auch zu einem späteren Zeitpunkt extrahiert werden können.(Marz N. & Warren J. 2015, 36) Daten sollen unveränderlich Daten werden persistiert und der Wert bleibt beim Hinzufügen sein neuer Werte erhalten. Neue Werte erzeugen eine neue Datenstruktur. Daten werden nicht aktualisiert oder gelöscht, nur hinzugefügt. (Marz N. & Warren J. 2015, 36) Daten sollen „eternally true“ Diese Anforderung steht in Abhängigkeit mit Unveränderlichsein keit. Daten werden mit einem Zeitstempel versehen und sind ab dann auf Dauer gültig - „eternally true“. (Marz N. & Warren J. 2015, 36) High-Level-Big-Data-Anforderungen Name (des Bausteins) Erläuterung Volume Große Datenmengen im Terabyte, Petabyte Bereich sollen verarbeitet werden können (Khaki S. 2016). 56 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Velocity Echtzeit-Verarbeitung von großen Datenströmen sollte möglich sein (Dorschel J. 2015, 264). Variety Verschiedene Datenformate und Datenquellen werden unterstützt (Dorschel J. 2015, 264). Veracity Metadatenintegration für unterschiedliche Datenquellen wird ermöglicht und Datenqualität gewährleistet (Dorschel J. 2015, 264). Systemeigenschaften Name (des Bausteins) Erläuterung Konsistenz (C) Konsistenz (C) bedeutet, dass es immer nur eine Single UpTo-Date Kopie von Daten gibt, Replikate sind identisch (Brewer E. 2012, 1). Verfügbarkeit (A) Verfügbarkeit (A) beschreibt das Maß, dass Anfragen an das System in einem bestimmten Zeitraum beantwortet werden können (Brewer E. 2012, 1). Partitionztoleranz (P) Partitionstoleranz (P) beschreibt die Ausfalltoleranz eines Systems, bei Verlust einer Partition des Netzes arbeitet das System weiter (Brewer E. 2012, 1). Konsistenz (C) Konsistenz (C) bedeutet, dass es immer nur eine Single UpTo-Date Kopie von Daten gibt, Replikate sind identisch (Brewer E. 2012, 1). Qualitätsmerkmale Name (des Bausteins) Erläuterung Robustheit Hier wird die Zuverlässigkeit des Systems beschrieben. Wenn bei einem verteilten System ein System ausfällt, soll das Gesamtsystem korrekt weiterarbeiten können. Komplexitäten sollten vermieden werden (Marz N. & Warren J. 2015, 7). Fehlertoleranz Systemtoleranz gegenüber menschlichen Fehlern ist gegeben. Neuberechnungen sollten möglich sein. Die Rohdaten bleiben unveränderlich (Marz N. & Warren J. 2015, 7). Niedrige Latenzzeit Die benötigte Zeit für Lese-Vorgänge sollte zwischen wenigen Millisekunden und einiger hundert Millisekunden liegen. Die Latenzzeiten für Updates müssen wenn benötigt gering gehalten werden können (Marz N. & Warren J. 2015, 7). Skalierbarkeit Skalierbarkeit beschreibt die Eigenschaft eines Systems, den steigenden Ansprüchen an Leistungsfähigkeit gerecht werden zu können (NIST 2015, 10). Bei steigenden Datenmengen können beispielweise Ressourcen hinzugefügt werden, um die nötige Effizienz gewährleisten zu können (Marz N. & Warren J. 2015, 7). 57 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Es sollte die Möglichkeit bestehen, eine Ergänzung von Funk- Erweiterbarkeit tionalitäten mit minimalen Aufwand zu einem System vornehmen zu können (Marz N. & Warren J. 2015, 7). Das System sollte verschiedene Applikationen unterstützen Generalisierung können (Marz N. & Warren J. 2015, 7). Das System bietet dem Benutzer die Möglichkeit, Inhalt und Ad hoc Queries Aussehen der Auswertungen für einen bestimmten Zweck auswählen zu können (Marz N. & Warren J. 2015, 9). Minimale Wartbarkeit Wartbarkeit beschreibt das Maß an Aufwand, der verwendet werden muss, damit ein System reibungslos funktioniert. Minimaler Wartungsaufwand wird durch Reduktion der Komplexität für die Implementation erzielt (Marz N. & Warren J. 2015, 9). Debug-Möglichkeiten Die Nachvollziehbarkeit von Daten für das Debugging bei Fehlläufen gegeben sein (Marz N. & Warren J. 2015, 9). Tabelle 9: Subkriterium Anforderungen (eigene Darstellung) Kriterium 6: Risiken Kriterium Name Beschreibung Risiken An dieser Stelle sollen die Risiken im Zuge des Einsatzes eines Systems identifiziert werden. Bei der Entscheidung für ein System werden Abwägungen getroffen, nicht alle Anforderungen werden erfüllt. Subkriterium Sensitivitätsprunkte Sensitivitätspunkte (engl. sensitivity points) sind Eigenschaften von Softwareelementen, die kritisch sind für die Erreichung eines Qualitätsmerkmals (Malich S. 2008, 85). Abwägungspunkte Abwägungspunkte (engl. tradeoff points) hingegen sind Eigenschaften, die kritisch sind für die Erreichung mehrere Qualitätsmerkmale (Malich S. 2008, 85). Tabelle 10: Kriterium Risiken Kriterium 7: Reifegrad Kriterium Name Beschreibung Reifegrad In diesem Kriterium soll der Reifegrad der Referenzarchitektur festgestellt werden. 58 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Subkriterium Ingestions-Phase Die Referenzarchitektur wurde in Internetquellen beispielsweise Videos, Blogs - beschrieben und noch nicht praktisch erprobt. Entwicklungsphase Die Referenzarchitektur wurde in Internetquellen beispielsweise Videos, Blogs - beschrieben und wurde bereits praktisch erprobt. Differenzierungsphase Die Referenzarchitektur wurde in der Literatur beschrieben und Verbesserungen auf Basis von praktischen Erfahrungen wurden vorgenommen. Ruhe-Phase Referenzarchitekturen auf Basis von neuen Erkenntnissen wurden designed und stellen lösen das aktuelle Architekturmuster ab. Tabelle 11: Kriterium Reifegrad Kriterium 8: Referenzen Kriterium Name Beschreibung Referenzen An dieser Stelle werden namenhafte Referenzen identifiziert. Tabelle 12: Kriterium Referenzen (eigene Darstellung) Taxonomie zur Klassifikation und Vergleich von Big-Data-Architekturen An dieser Stelle sollen die genannten Kriterien noch einmal als Gesamtübersicht dargestellt werden. Kriterium Beschreibung Kriterium 1: Kurzbe- Die Grundzüge der Architektur soll in 4-5 Sätzen beschrieben werden schreibung Kriterium 2: Haupt- Referenzarchitekturen können für verschiedene Zielsetzungen konzi- ziel piert werden. Keine Architektur kann alle Ziele gleichermaßen erfüllen. Hier soll das Hauptziel identifiziert werden. Kriterium 3: Annah- Für die Konzeption einer Referenzarchitektur werden bestimmte men Grundannahmen getroffen. Diese sollen hier identifiziert werden. Kriterium 4: Para- Einer Referenzarchitektur werden verschiedene Paradigmen zu digmen Grunde gelegt. Diese sollen an dieser Stelle identifiziert werden, um beispielsweise zu einem späteren Zeitpunkt des Entscheidungsfindungsprozess die zielgerichtete Technologieauswahl treffen zu können. Kriterium 5. Anfor- An dieser Stelle sollen die durch die Referenzarchitektur adressierten derungen Anforderungen identifiziert werden. 59 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Kriterium 6: Hier sollen die Risiken im Zuge des Einsatzes eines Systems identifi- Risiken ziert werden. Bei der Entscheidung für ein System werden verschiedene Abwägungen getroffen, es können nicht alle Anforderungen gleichermaßen erfüllt werden. Kriterium 7: Reife- In diesem Kriterium soll der Reifegrad der Referenzarchitektur festge- grad stellt werden. Kriterium 8: Refe- An dieser Stelle sollen namenhafte Referenzen identifiziert werden. renzen Tabelle 13: Taxonomie (eigene Darstellung) 5.2.2 Anwendung der Taxonomie am Beispiel des Vergleichs von Lambdaund Kappa-Architektur Unter Anwendung der entwickelten Taxonomie werden nun die beiden Referenz-Architekturen tabellarisch verglichen. Als Grundlage dient die im Kapitel 3.2.8. „Big-Data-Referenzarchitekturen“ beschriebene Theorie. Wie bereits in dem besagten Kapitel beschrieben, ist Nathan Marz der Mitentwickler der Lambda-Architektur und Jay Kreps der Entwickler der Kappa-Architektur. Aus diesem Grund stammen alle weiteren benötigten Informationen für die Prüfung der einzelnen Kriterien aus der Literatur von Nathan Marz („Big-Data- Principles and best practices of scalable real-time data systems) und dem Blog von Jay Kreps („Questioning the Lambda Architecture“). Kriterium Lambda-Architektur Kappa-Architektur Kurzbeschreibung Die Lambda-Architektur ist ein Archi- Die Kappa-Architektur ist ein tekturstil, der aus den Schichten - Architekturstil, der aus den Batch, Speed und Serving - besteht Schichten - Speed und Ser- und die Anforderungen von Big-Data ving - besteht und die Anfor- adressiert (Marcous D. 2015). derungen von Big-Data adressiert (Marcous D. 2015). Hauptziel Das Hauptziel des Architekturstils ist Das Hauptziel ist die Verbes- die Konzeption eines Big-Data-Sys- serung des Speed-Layers der tems basierend auf verschiedenen Lambda-Architektur, um so- Schichten, die unterschiedliche Funk- mit auf den Batch-Layer vertionen erfüllen und die mit der besten zichten zu können. Die Busi- Technologie bestückt werden. Daten ness Logik muss nur einmal sind unveränderlich. Echtzeit- und his- implementiert werden. torische Daten können prozessiert Schnelle Verarbeitung und werden. Jeder Prozess kann wieder- Gewährleistung der Unverän- holt und alle Daten können abgefragt derlichkeit von Daten sollen werden. (Marcous D. 2015). ein Log vorhalten, ein System 60 Bachelor Thesis Corinna Ludwig © CORE 2016 73 das dem Speed-Layer vorgeschaltet wird. Eine erneute Verarbeitung findet hier nur statt, wenn der Code für die Verarbeitung sich ändert. Diese erneute Verarbeitung wird parallel durch eine neue Instanz durchgeführt. (Kreps J. 2014) Annahmen 1. Es gibt keine technische Kompo- 1. Echt-Zeit-Verarbeitung ist nente, die eine Gesamtlösung bietet akkurat (Kreps J. 2014).. (Marz N. & Warren J. 2015, 14). 2. Echt-Zeit-Verarbeitung liefert Ap- 2. Wiederaufbereitung der proximationen, ist weniger leistungs- Daten ist nur bei Code-Ände- fähig und verlustanfälliger als eine rungen notwendig (Kreps J. Batch-Lösung (Kreps J. 2014). 2014). Die folgenden Schichten sind für den Die folgenden Schichten sind Datenzugriff vorgesehen für den Datenzugriff vorgese- Paradigmen Datenzugriff 1. Batch Layer: Batch Processing und hen: Reprozessierungsmöglichkeiten, 1. Stream Layer: Streaming 2. Stream Layer: Streaming Pro- Processing, cessing, 2. Query. 3. Query (Marz N. & Warren J. 2015). Die Verarbeitung erfolgt einmalig (=Exactly-Once-Processing). Reprozessierung erfolgt nur bei Veränderung des Codes (Kreps J. 2014). Datenhaltung Analytische Verarbei- Serving Layer: beispielsweise Relatio- Serving Layer: beispielsweise nale Datenbank oder In-Memory-Da- Distributed File System oder tenbank, In-Memory Datenbank und Batch Layer: Distributed File System der und der Speed Layer: NoSQL Daten- Speed Layer: NoSQL Datenbank bank (Marz N. & Warren J. 2015). (Kreps J. 2014). Keine Aussage von Marz Keine Aussage von Kreps tung 61 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Datenintegration Daten-Konnektoren: Queues und Daten-Konnektoren und Da- Messaging, ten-Ingestion: Messaging Daten-Ingestion: Marz trifft hierzu (Kreps J. 2014). keine Aussage. (Marz N. & Warren J. 2015, 225) Anforderungen Datenmodell-Anforderungen Daten sollen im Rohzu- Daten werden unstrukturiert gespeistand vorliegen Der Log enthält alle Events, chert (Marz N. & Warren J. 2015, 20). Daten werden im Rohzustand abgebildet und können jederzeit abgerufen werden. (Kreps J. 2013) Daten sollen unverän- Daten werden nicht verändert, son- Bei einem Log werden die derlich sein dern Datensätze werden gekenn- Daten nicht verändert; Trans- zeichnet und mit einem Timestamp aktionen werden v mit einem hinzugefügt (Marz N. & Warren J. neuen Timestamp festgehal- 2015, 20). ten. Informationen sind jederzeit nachvollziehbar. (Kreps J. 2013) Daten sollen „eternally Da Daten bis auf den Löschvorgang Daten sind unveränderlich true“ sein nicht verändert werden können, sind und damit „eternally true“ sie „eternally true“ (Marz N. & Warren Kreps J. 2013). J. 2015, 20). High-Level-Big-Data-Anforderungen Volume Die Anforderung an das Handling von Die Verarbeitung von großen großen Datenmengen wird durch Datenmengen wird durch Pa- Batch-Processing erfüllt (Marcous D. rallelisierung im Speed Layer 2015). gewährleistet. (Kreps J. 2013) Velocity Stream-Processing gewährleistet Ver- Stream-Processing gewährarbeitung in Echtzeit leistet Verarbeitung in Echt- (Marcous D. 2015). zeit (Marcous D. 2015). Variety Verschiedene Datenformate werden Verschiedene Datenformate durch NoSQL Datenbanken im werden durch NoSQL Daten- Speed-Layer verarbeitet (Marcous D. banken im Speed-Layer ver- 2015). arbeitet und vorher im Log gespeichert (Kreps J. 2013). 62 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Veracity Daten werden im Rohzustand gespei- Daten werden im Rohzustand chert und bleiben unverändert; die gespeichert und bleiben un- Anforderung an Veracity wird somit verändert; die Anforderung erfüllt an Veracity wird somit erfüllt (Marcous D. 2015). (Marcous D. 2015). Systemeigenschaften Konsistenz (C) Da zwei Business-Logiken implemen- Bei Ausfällen oder Fehlern in tiert und asynchron prozessiert wer- der Prozessierung, kann den, ist Konsistenz nicht gegeben keine Konsistenz der Daten (Kreps J. 2014). zwischen Log und ServingLayer gewährleistet werden (Kreps J. 2014). Verfügbarkeit (A) Verfügbarkeit wird durch den Speed- Verfügbarkeit wird durch den Layer gewährleistet (Marz N. & War- Speed-Layer gewährleistet ren J. 2015, 212). (Marz N. & Warren J. 2015, 212). Partitionztoleranz (P) Das Distributed File System des Die Verarbeitung kann auch Batch Layers erfüllt die Anforderun- in partitionierten Zustand un- gen an Partitionstoleranz (Marz N. & ter Berücksichtigung der Warren J. 2015, 212). Exactly-Once-ProcessingGarantie erfolgen (Kreps J. 2014). Qualitätsmerkmale Robustheit Wird durch den Batch-Layer und Ser- Der Server Layer verwendet ver-Layer erfüllt. Replikationen als Instrument, Das Distributed File System des um Verfügbarkeit der Daten Batch Layers fängt Systemausfälle bei Systemausfall zu gewähr- ab. leisten. (Marz N. & Warren J. Server Layer benutzt Replikationen, 2015, 177). um Verfügbarkeit der Daten bei Systemausfall zu gewährleisten (Marz N. & Warren J. 2015, 177). Fehlertoleranz Das System lässt eine hohe Fehlerto- Das System lässt eine hohe leranz zu. Fehlertoleranz zu. Durch Menschen verursachte Fehler Die Wiederherstellbarkeit der werden durch die kontinuierliche Wie- verarbeiteten Daten wird derherstellung der aggregierten Daten durch die Dokumentation der in Batch-Sichten im Serving Layer im Informationen über die zu Zuge des Rückgriffs auf das Master verwertenden Daten in einem Data Set korrigiert. Die Daten sind un- Log sichergestellt. Hier werveränderlich, nur die Ergebnisse den alle Transaktionen mit 63 Bachelor Thesis Corinna Ludwig © CORE 2016 73 durch den Algorithmus können ver- Zeitstempel festgehal- worfen werden.(Marz N. & Warren J. ten.(Kreps J. 2013) 2015, 20) Niedrige Latenzzeit Der Batch Layer hat eine hohe Latenzzeit, Berechnungen können mehrere Stunden dauern. Der Speed Layer hat eine niedrige La- Der Speed Layer hat eine Skalierbarkeit tenzzeit. (Marz N. & Warren J. 2015, niedrige Latenzzeit.(Kreps J. 20). 2014) Serving, Speed und Batch-Layer sind Serving und Speed-Layer verteilte Systeme, horizontale Skalier- sind verteilte Systeme, horibarkeit wird gewährleistet (Marz N. & zontale Skalierbarkeit wird Warren J. 2015, 20). gewährleistet (Marz N. & Warren J. 2015, 20). Erweiterbarkeit Neue Daten und Funktionen können Anders als bei der Lambda- der Berechnung des Master Datasets Architektur die jetzigen Sich- im Batch Layer hinzugefügt werden, ten mit den Masterdaten zu durch Re-Prozessierung werden neue überschreiben, wird für die Sichten im Serving Layer er- erneute Verarbeitung bei der zeugt.(Marz N. & Warren J. 2015, 17). Architektur eine neue Instanz innerhalb des Speed-Layers gestartet. Erweiterbarkeit ist also möglich. (Kreps J. 2014) Generalisierung Die Anforderung der Generalisierung Der Zeitstempel der neu zu wird erfüllt. Beliebig viele Sichten ei- verarbeitenden Daten ist in- nes Datenbestandes können erzeugt nerhalb des Logs beliebig se- werden. (Marz N. & Warren J. 2015, lektierbar (jetzt, vor einem 17). Tag, vor einem Jahr), die Daten werden erneut verarbeitet und in eine neue Output-Tabelle geschrieben. (Kreps J. 2014) Ad hoc Queries Batch Layer unterstützt Ad Hoc Die zu lesenden Daten könn- Queries. Informationen sind alle an ei- ten zeitpunktbezogen aus nem Ort verfügbar. (Marz N. & War- dem Log selektiert, in Echt- ren J. 2015, 18). zeit prozessiert und im Serving-Layer bereitgestellt werden; demnach sind Ad hoc Queries möglich. (Kreps J. 2014) 64 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Minimale Wartbarkeit Der Wartungsaufwand von zwei Sys- Da nur ein System für die temen - dem Batch Layer und dem Prozessierung der Daten ver- Speed Layer - in denen die Business- wendet wird, ist der Grad an Logik implementiert wird, ist höher als Wartbarkeit gering (Kreps J. DebugMöglichkeiten bei einem System. (Kreps J. 2014) 2014). Das Wissen über Inputparameter Da alle Informationen über (Master Dataset) und Output (Sichten) die Daten in Logdateien gedes Batch-Layers bieten alle Informa- halten werden, ist Debugging tionen, um Debugging vorzuneh- einfach durchführbar. (Kreps men(Marz N. & Warren J. 2015). Den- J. 2014) noch müssen in zwei Systemen Fehler gesucht werden. Der Aufwand für die Fehlersuche ist höher als bei nur einem System. (Kreps J. 2014) Risiken Sensitivitätspunkte Abwägungspunkte Die lange Verarbeitungszeit des Da die Prozessierung von Batch-Layers bedingt die Existenz Echtzeit-Daten und histori- des Speed-Layers. Der Anforderung schen Daten in der gleichen einer niedrigen Latenzzeit wird somit Schicht abläuft, wird das nur bedingt Rechnung getragen. Zweifache an Speicherplatz (Kreps J. 2014) benötigt. (Kreps J. 2014) Die Business-Logik in zwei Systemen Bei der parallelen Prozessiezu implementieren, läuft den Erwar- rung von großen historischen tungen an minimale Wartbarkeit und Datenbestände, könnte der einfachen Debug-Möglichkeiten ent- erhöhte Rechenaufwand gegen. (Kreps J. 2014) dazu führen, dass für die Echtzeit-Verarbeitung ein neues Cluster eröffnet werden muss. Die Performance könnte darunter leiden. (Kreps J. 2014) Reifegrad Der Architekturansatz befindet sich in Der Architekturansatz befin- der Differenzierungsphase, das Mus- det sich in der Entwicklungs- ter wurde bereits in der Literatur doku- phase, das Muster wurde bementiert und mehrfach erprobt (siehe reits auf verschiedenen Blogs Referenzen). beschrieben und mehrfach erprobt (siehe Referenzen), die Dokumentation in der Literatur steht noch aus. 65 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Referenzen Twitter, Spotify, Liveperson, Innerac- LinkedIn, Yahoo tive Tabelle 14: Vergleich von Lambda- und Kappa-Architektur (eigene Darstellung) 5.2.3 Konkretisierung des Scoring-Modells und Ausgestaltung Im Theoriekapitel 4.2. „Das Scoring-Modell“ wurde bereits das allgemeine Vorgehen für die Anwendung eines Scoring-Modells beschrieben. Das Scoring wird in der Folge lediglich auf Kriterium 5. Anfrderungen angewendet da lediglich diese objektiv quantifizierbar sind. Alle weiteren Kriterien wurden im Kapitel 5.2.2. bereits indikativ gegenübergestellt. Risiken, Reifegrad und Referenzen könnten als zusätzliche Kriterien zur Entscheidungshilfe herangezogen, sollen im Rahmen dieser Arbeit jedoch nicht quantifiziert werden. Vorgehen A. Alle relevanten Kriterien werden identifiziert. Innerhalb der Taxonomie wurden alle bewertungsrelevanten Kriterien identifiziert. B. Evaluierungskriterien können in Haupt- und Unterkategorien unterteilt werden. Die Kriterien wurden in Haupt- und Subkriterien untergliedert. C. Jedem Kriterium wird eine Gewichtung zugewiesen. Maximal 100 Prozent in Prozentanteilen oder numerische Werten können vergeben werden. Bei Zahlen muss eine Höchstzahl vergeben werden. D. Prüfung ob die Vergabe der Gewichtung auch der Wichtigkeit der Anforderung entspricht. Bei der Betrachtung eines Use-Cases in einem Versicherungsunternehmen würden die Anforderungen verschieden priorisiert und gewichtet werden. An dieser Stelle soll aus Vereinfachungszwecken der individuelle Use-Case nicht betrachtet werden, sondern aus generischer Sicht die Architekturen bewertet werden, somit wird jede Anforderung gleich gewichtet. Die Zuweisung wird über numerische Werte vorgenommen. Die Skala mit aufsteigender Wichtigkeit von 1 bis 4 wird zu Grunde gelegt. Diese Skala basiert auf der Priorisierungsmethode für Anforderungen MoSCoW und spielt vier Stufen wider: MUST (unbedingt erforderlich) = Stufe 4, SHOULD (sollte umgesetzt werden) = Stufe 3, COULD (kann umgesetzt werden) = Stufe 2 und WON’T (wird diesmal nicht umgesetzt) = Stufe 1 (Drather, Koschek & Sahling 2013) Die Höchstzahl wäre demnach 4 und jede Anforderung wird mit der Zahl 4 gewichtet. E. Für jedes Kriterium wird für jede Option eine Punktzahl vergeben. Die höchstmöglich zu vergebende Punktzahl wird vorher festgelegt. 66 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Für die jeweiligen Optionen werden in der Bewertung im nächsten Kapitel die Punkte festgelegt. Für die Festlegung der zu vergebenden Punktzahl wird eine Skala von eins bis drei gewählt. Die Bewertung ist wie in der Theorie beschrieben subjektiv: Bewertung in Punkten Erklärung 1 Die niedrigste Punktzahl wird vergeben bei einem geringen Erfüllungsgrad der Anforderung. 2 Die mittlere Punktzahl wird vergeben bei einem mittleren Erfüllungsgrad der Anforderung. 3 Die Höchstanzahl wird vergeben bei Erfüllung der Anforderung. Tabelle 15: Bewertungsskala (eigene Darstellung) Im nächsten Kapitel wird der Punkt 5 zu Ende geführt sowie die Punkte 6 und 7 durchgeführt. F. Die Gewichtungen und Punktzahlen werden multipliziert und die endgültige Punktzahl für jedes Kriterium ermittelt. Die endgültigen Punktzahlen aller Kriterien summieren ergeben den endgültigen Punktestand für die Option. (Andler N. 2007, 407) 5.2.4 Anwendung der Bewertungsmethode am Beispiel des Vergleichs von Lambda- und Kappa-Architektur Das Scoring-Modell für die Lambda- und Kappa-Architektur soll als Bewertungsrundlage dienen. Die beschriebene gleichverteilte Gewichtung ist in der Spalte Gewichtung wiederzufinden. Die Vergabe der Punkte wurde auf Basis der subjektiven Einschätzung der Ergebnisse aus der tabellarischen Gegenüberstellung vorgenommen (Kapitel 5.2.2.). Die Bewertung wäre in der Praxis von relevanten Stakeholdern zu validieren. Scoring-Modell für Lambda- und Kappa Architektur Kriterium: Gewichtung Lambda-Architektur Kappa-Architektur Punkte Bewertung Punkte Bewertung 4 3 12 3 12 4 3 12 3 12 4 3 12 3 12 Anforderung Datenmodell-Anforderungen Daten sollen im Rohzustand vorliegen Daten sollen unveränderlich sein Daten sollen „eternally true“ sein 67 Bachelor Thesis Corinna Ludwig © CORE 2016 73 High-Level-Big-Data-Anforderungen Volume 4 3 12 3 12 Velocity 4 3 12 3 12 Variety 4 3 12 3 12 Veracity 4 3 12 3 12 Systemeigenschaften Konsistenz (C) 4 1 4 1 4 Verfügbarkeit (A) 4 3 12 3 12 Partitionztoleranz (P) 4 3 12 3 12 Qualitätsmerkmale Robustheit 4 3 12 2 8 Fehlertoleranz 4 3 12 3 12 Niedrige Latenzzeit 4 2 8 3 12 Skalierbarkeit 4 3 12 3 12 Erweiterbarkeit 4 3 12 3 12 Generalisierung 4 3 12 3 12 Ad hoc Queries 4 2 8 3 12 Minimale Wartbarkeit 4 1 4 3 12 Debug-Möglichkeiten 4 1 4 3 12 Summe 47 208 54 240 76 Tabelle 16: Scoring-Modell (eigene Darstellung) 5.2.5 Erkenntnisse und Folgerungen Im diesem Kapitel wird dargelegt, inwiefern die verbleibenden Forschungsfragen mit dem vorgelegten Modell beantwortet werden können. Analog zur Diskussion des ersten Gliedes der Forschungsfragen werden Grenzen dieser theoretischen Untersuchung aufgezeigt und Ansätze zu ihrer Überwindung in der Praxis vorgeschlagen. Die folgenden Forschungsfragen konnten beantwortet werden: F2: Wie könnte ein Modell zur Objektivierung der Architekturentscheidung für Big-DataLösungen aussehen? F3: Welche Ergebnisse liefern der Vergleich und die Bewertung ausgewählter Architekturen mit Hilfe des Modells? Für die Beantwortung der Forschungsfrage F1 wurde eine Taxonomie entwickelt. Diese Taxonomie basiert auf acht Kriterien: Kriterium 1: Kurzbeschreibung, Kriterium 2: Hauptziel, Kriterium 3: Annahmen, 68 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Kriterium 4: Paradigmen, Kriterium 5. Anforderungen, Kriterium 6: Risiken, Kriterium 7: Reifegrad und Kriterium 8: Referenzen. Die Kriterien wurden benannt, beschrieben und in Subkriterien untergliedert. Die Subkriterien wurden ebenfalls benannt und beschrieben. Die Ableitung der Kriterien basierte auf dem Gesamtverständnis der theoretischen Grundlagen. Die Kriterien 1-4 dienen der indikativen Gegenüberstellung, die Kriterien 5-8 dienen der objektiven Quantifizierung. In dieser Arbeit wurde die Grundlage für die quantitative Analyse der Architekturen auf Basis des Kriteriums 5 bereits gelegt. Für die Bewertung wird das Scoring- Modell als Analyseinstrument zur Objektivierung herangezogen. Die Gewichtung der Anforderungen für die Bewertung der Architekturen erfolgt nach der beschriebenen Priorisierungsmethode MoSCoW und der Punktevergabe wird eine Bewertungsskala von 1-3 nach aufsteigendem Erfüllungsgrad der Anforderung. Im Ergebnis wurde ein Modell - hier Taxonomie - entwickelt, dass eine Objektivierung unter Verwendung von qualitativen sowie quantifizierbaren Kriterien und der Bewertung innerhalb eines Scoring Modells ermöglicht. Für die Beantwortung der Forschungsfrage F2 wurde anhand des entwickelten Modells die ausgewählten Architekturen - Lambda- und Kappa-Architektur - tabellarisch gegenübergestellt und im nächsten Schritt basierend auf dem Vergleich bewertet. Die Erprobung der Taxonomie (Kapitel 5.2.2. und Kapitel 5.2.4.) und der vorgenommenen Bewertung zeigt: Einen Überblick über die Konzeption der betrachteten Architekturen, Wesentliche Unterschiede in ihren Merkmalen, Anhaltspunkte für Risiken und eine Gesamtscheinschätzung durch den Vergleich der Gesamtpunktestände. Am Beispiel von der Lambda- und Kappa-Architektur ist die Kappa-Architektur mit einem deutlichen Punktevorsprung nach erster Einschätzung der Gewinner. Diese Informationen können als Grundlage für den weiteren Architekturentscheidungsfindungsprozess im Sinne der Forschungsfrage dienen. Allerdings sind die qualitativen Unterscheidungen und Auswirkungen auf tatsächliche Big-DataArchitekturen erheblich. An dieser Stelle sollen daher die Grenzen im Rahmen dieser theoretischen Betrachtung aufgezeigt werden. Zunächst sollen kritische Punkte der Taxonomie aufgezeigt werden. Die Benennung der Kriterien unterscheidet nicht zwischen dessen subjektiver oder objektiver Natur. Die Bemessungsgrundlage für die Bewertung waren allgemeingültige gleichgewichtete Anforderungen. Es fand keine 69 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Überprüfung der Taxonomie anhand eines verifizierten Anwendungsfalls in der Praxis statt. Die Bewertung erfolgte auf Basis einer Einzelbetrachtung, keine weiteren Stakeholder wurden mit einbezogen. Die vorliegende Einschätzung bewertet die Kappa-Architektur besser, diese Aussage lässt sich jedoch nur mit Einschränkungen verallgemeinern. Viele der beschriebenen Anforderungen - wie beispielspeise Skalierbarkeit oder Fehlertoleranz- werden bei beiden Architekturen erfüllt. Es gibt verschiedene Kriterien in denen sich die Architekturen unterscheiden. Beispielsweise muss bei der Lambda-Architektur der Speed-Layer die hohe Latenzzeit des Batch-Layers ausgleichen. Bei der Kappa-Architektur erfüllt der Speed-Layer die gewünschte Anforderung der niedrigen Latenzzeit. Bei der Wartbarkeit ist festzustellen, dass bei der Lambda-Architektur der Wartungsaufwand deutlich höher ist. Dies wird durch die Implementierung von zwei Business-Logiken begründet, im Gegensatz dazu ist bei der Kappa-Architektur nur eine Logik zu implementieren. Dieser Punkt ist insbesondere für Entwickler und Tester von Relevanz. Daraus abgeleitet unterscheiden sich die Lambda- und Kappa-Architekturen in dem Vergleich ihrer Risiken. Der angesprochene Konflikt der Latenzzeit ist ein Sensitivitätspunkt der LambdaArchitektur. Business-Logik in zwei Systemen zu implementieren läuft den Erwartungen an minimale Wartungsaufwände und einfachen Debug-Möglichkeiten entgegen und ist somit ein Abwägungspunkt. Für die Prozessierung von Echtzeit- und historischen Daten in der gleichen Schicht wird das Zweifache an Speicherplatz benötigt. Dies stellt einen Sensitivitätspunkt der Kappa-Architektur dar. Bei paralleler Prozessierung von großen Datenbeständen könnte der erhöhte Rechenaufwand zur Eröffnung eines neuen Clusters und geringerer Performance führen. Die verschlechterte Performance ist ein Abwägungspunkt der Kappa-Architektur. Des Weiteren unterscheiden sich die Architekturen in ihrem Reifegrad. Die Lambda-Architektur wurde mehrfach verprobt und bereits in der Literatur dokumentiert. Die Kappa-Architektur wurde nicht weiter in der Literatur beschrieben. Es ist festzustellen, dass die Taxonomie Grenzen aufweist und dass die Bewertung von Kappaund Lambda-Architektur differenziert zu betrachten ist. An dieser Stelle sollen die Erkenntnisse synthetisiert werden. Die Taxonomie ist für die in der Arbeit untersuchte Objektivierung der Architekturentscheidung anwendbar. In der Praxis könnten Verbesserungen vorgenommen werden. Da kein konkreter Use-Case betrachtet wurde ist das Aussehen dieser Taxonomie generischer Natur. Kriterien wie die Anforderungen an eine BigData-Lösung sind allgemeingültig und daher hier als Bemessungsgrundlage verwendet worden. Die Taxonomie ist auf somit auf Erweiterbarkeit zu prüfen. Beispielsweise könnten die im Kapitel 3.1.3 beschriebenen Qualitätsanforderungen Betrachtung finden. Für den konkreten Anwendungsfall im Unternehmen muss unter Berücksichtigung der individuellen Anforderungen die Taxonomie geprüft, erweitert oder verändert werden. Für die Bewertung sollten die relevanten Stakeholder hinzugezogen werden. Für die Anwendung der Taxonomie könnte zudem ein definiertes Vorgehen beschrieben und eine Visualisierung der Einordnung Taxonomie im Gesamtlebenszyklus stattfinden. Diese beschriebene Erweiterbarkeit und Überprüfung anhand eines Use-Cases 70 Bachelor Thesis Corinna Ludwig © CORE 2016 73 führt zu einer differenzierteren Sicht auf die Unterschiede der Architekturen im spezifischen Kontext. Hier müssen individuell alle Anforderungen gegeneinander abgewogen werden. Es lässt sich festhalten, dass die Taxonomie eine gute Basis für die Weiterentwicklung und Erprobung in der Praxis bietet und eine Objektivierung ermöglicht. 71 Bachelor Thesis Corinna Ludwig © CORE 2016 73 6 Schluss 6.1 Zusammenfassung Ziel der Bachelorarbeit war es, einen Überblick über das Thema Big-Data zu geben. Dazu war die Relevanz von Big-Data-Lösungen für Versicherungen aufzuzeigen und die Entscheidungsfindung für eine Big-Data-Architektur zu objektivieren. Ausgehend von einer vergleichenden Bewertung ausgewählter Architekturen waren Grenzen im Rahmen dieser theoretischen Untersuchung aufzuzeigen und ein Ausblick auf weitere Schritte entlang des Entscheidungsprozesses für eine Zielarchitektur zu geben. Konkret waren folgenden Forschungsfragen zu beantworten: F1: Ist der Einsatz von Big-Data für ein Versicherungsunternehmen von Relevanz? F2: Wie könnte ein Modell zur Objektivierung der Architekturentscheidung für Big-DataLösungen aussehen? F3: Welche Ergebnisse liefern der Vergleich und die Bewertung ausgewählter Architekturen mit Hilfe des Modells? A. Der Überblick über das Thema Big-Data wurde gegeben. Eine strukturierte Beschreibung des Big-Data-Ökosystems gibt es in der Literatur nur in Ansätzen. Zur Vorstellung des Themas Big-Data wurden deshalb aus verschiedenen Quellen die Informationen aggregiert und strukturiert. Der Überblick dient als Versuch, diese Forschungslücke zu schließen. Der Überblick über das Thema Big-Data bietet das Kapitel 3.2. „Big-Data-Technologien“ stellt den Eckpfeiler für die Arbeit dar: Zur Einleitung in das Thema wurden verschiedene Big-Data-Definitionen vorgestellt, neue Entwicklungen im Bereich der Datenmodelle wurden durch eine Einführung in NoSQL sowie einer Abgrenzung zu relationalen Modellen aufgezeigt, die Wichtigkeit über die Kenntnis der Daten stellte die Überleitung zur Klassifikation von Daten dar und der Vorstellung des Datenlebenszyklus, sowie eine Beschreibung der durch die Vielfalt an Daten bedingten Anzahl an Schichten und Bausteinen einer Big-Data-Lösung erfolgt, die Einführung der Schichten und Bausteine einer Big-Data-Lösung bildete die Herleitung zu dem Thema Big-Data-Referenzarchitekturen, deren Prinzipien und die Vorstellung von Lambda- und Kappa-Architektur. B. Die Relevanz von Big-Data für Versicherungen wurde gezeigt. Für die Beantwortung der Forschungsfragen wurden Chancen sowie Herausforderungen bei der Einführung sowie einer Weiterarbeit mit bisherigen Lösungen identifiziert. Die umfassenden Chancen bei der Einführung einer Big-Data-Lösung überwiegen die assoziierten Herausforderungen deutlich. Gleichzeitig kann die Fortführung bestehender Modelle keine deutlichen Vorteile 72 Bachelor Thesis Corinna Ludwig © CORE 2016 73 generieren. Die Nutzung der Big-Data-Lösungen ist zu bevorzugen und ist somit von Relevanz für Versicherungen. C. Ein Modell für den Vergleich und Bewertung wurde entwickelt. Identifiziert ein Unternehmen eine Relevanz für eine technische Lösung, so wird sich entlang des Entscheidungsprozesses die Frage nach der Auswahl einer Architektur stellen. Diese Erkenntnis diente der Überleitung zur Objektivierung der Entscheidungsfindung einer Big-Data-Architektur. Die Objektivierung der Architekturentscheidung in einem frühen Stadium wurde bisher nicht in der Literatur beschrieben. Die hierzu entwickelte Taxonomie für den Vergleich soll einen ersten Ansatz bieten diese Forschungslücke zu schließen. Für die Objektivierung wurde die vorgeschlagene Taxonomie mittels eines Scoring-Modells bewertet. Für die Entwicklung der Taxonomie wurden Teile der theoretischen Grundlagen aus dem Kapitel 3.2. „Big-Data-Technologien“ herangezogen und zu acht Kriterien sowie Subkriterien verdichtet: 1. Kurzbeschreibung, 2. Hauptziel, 3. Annahmen, 4. Paradigmen, 5. Anforderungen, 6. Risiken und 7. Reifegrad sowie 8. Referenzen. Die Ableitung der Kriterien basierte auf dem Gesamtverständnis der theoretischen Grundlagen. Die Kriterien 1-4 dienten der indikativen Gegenüberstellung, die Kriterien 5-8 tragen einer objektiven Quantifizierung Rechnung. Die Bewertung erfolgte auf Basis eines Scoring-Modells und der Betrachtung des 5. Kriteriums (Anforderungen). Die Gewichtung der Anforderungen erfolgte auf einer aus der Anforderungshebung stammenden Priorisierungsmethode. D. Erkenntnisse aus dem Vergleich und der Bewertung konnten abgeleitet werden. Die Erprobung der Taxonomie (Kapitel 5.2.2. und Kapitel 5.2.4.) hat im bewerteten Vergleich folgende Ergebnisse produziert: Ein generischer Überblick über die Konzeption der Architektur wurde ermöglicht, die Unterschiede der Referenzarchitekturen offengelegt, Anhaltspunkte für Risiken identifiziert und eine erst Gesamteinschätzung auf Basis der Punktevergabe getroffen. Am Beispiel von der Lambda- und Kappa-Architektur konnte die Kappa-Architektur mit einem deutlichen Punktevorsprung nach erster Einschätzung als Gewinner identifiziert werden. Diese Informationen können als Grundlage für den weiteren Architekturentscheidungsfindungsprozess dienen. Die Forschungsfrage wurde beantwortet und das Modell auf erste Tragfähigkeit überprüft. An dieser Stelle sollen die Grenzen der theoretischen Betrachtung noch einmal zusammengefasst werden. Das für die Analyse der Relevanz von Big-Data für Versicherungen verwendete kartesische Koordinatensystem dient der ersten Strukturierung der eigenen Gedanken zu einer Ursache-Wirkungs-Beziehung. Es wurde ein Ausschnitt der Literatur betrachtet. Die Argumente wurden nicht weiter quantifiziert. Sichtweisen wie Stärken- und Schwächen des Unternehmens oder andere Wirkungsmechanismen wurden nicht betrachtet. 73 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Das verwendete Modell für den Vergleich und die Bewertung der Architekturstile unterscheidet nicht zwischen Kriterien subjektiver und objektiver Natur. Anforderungen wurden gleichgewichtet. Die Taxonomie wurde bislang nicht praxiserprobt Die vorliegende Einschätzung bewertet die Kappa-Architektur besser, diese Aussage lässt sich jedoch nur mit Einschränkungen verallgemeinern. Die Sensitivitätspunkte sowie Abwägungspunkte unterscheiden sich. Da sich Anforderungen in der Praxis ebenso differenzieren, wäre eine Bewertung in Einzelfall erneut vorzunehmen. Insgesamt kann festgestellt werden, dass das Thema Big-Data einen hohen Grad an Komplexität aufweist, Indizien für die Relevanz von Big-Data im Versicherungsunternehmen gegeben sind und das vorgestellte Modell einen ersten Ansatz für die Objektivierung der Architekturentscheidung bietet. 6.2 Ausblick Ausgehend von der Synthese der gewonnenen Erkenntnisse soll nun ein Ausblick auf den Entscheidungsprozesses für eine Zielarchitektur in der Praxis gegeben werden. In meiner Arbeit habe ich erste Indizien für die Relevanz von Big-Data identifiziert. Die Frage nach der Relevanz sollte in der Praxis unter Berücksichtigung von weiteren Faktoren - beispielsweise sozio-kulturellen oder politischen Veränderungen - weiter quantifiziert und empirisch untersucht werden. An dieser Stelle könnten zusätzlich messbare Kennzahlen und Expertenmeinungen herangezogen werden. Die Analyse sollte in Einzelfall quantifiziert werden. Die Taxonomie ist für die in der Arbeit untersuchte Objektivierung der Architekturentscheidung anwendbar. In der Praxis könnten Verbesserungen vorgenommen werden: Die generische Taxonomie ist auf Basis weiterer Analysen auf Erweiterbarkeit zu prüfen und beispielsweise weitere Qualitätsmerkmale inkludiert werden. Für die Bewertung sollten die relevanten Stakeholder hinzugezogen werden. Die Taxonomie könnte durch eine Vorgehensbeschreibung ergänzt werden. In meiner Arbeit habe ich exemplarisch die bekanntesten Architekturen Lambda- und Kappa-Architektur gegenübergestellt und bewertet. Das erarbeitete Klassifikationsschema kann als Grundlage für die Analyse und Bewertung weiterer Architekturen (zum Beispiel iot-a-, Zeta- und MuArchitektur) dienen, aber auch die Bewertung für die Lambda- und Kappa-Architekturen sind entlang unternehmensspezifischer Anforderungen zu validieren. Nach der Identifikation und Spezifizierung entsprechender Anwendungsfälle einer Big-Data Lösung in der Versicherungsbranche, zum Beispiel 360 Grad Sicht auf den Kunden in Marketing und Vertrieb, Betrugserkennung im Risiko- und Schadensmanagement, Innovationen und -Pricing in der Produktentwicklung, kann die realitätsnahe Erprobung der beschriebenen Taxonomien erfolgen. Aufgrund der neu gewonnenen Erkenntnisse sollte das ermittelte Modell verfeinert und weiterentwickelt werden. Nachdem der IT-Architekt die verschiedenen Architekturen unter Berücksichtigung der relevanten Anwendungsfälle vergleichen und bewerten konnte, wäre der nächste Schritt entlang des Software-Architektur-Lebenszyklus die Erstellung eines ersten Entwurfs einer Architektur auf Basis des unternehmensspezifischen Datenmodells unter Berücksichtigung der relevanten Anliegen 74 Bachelor Thesis Corinna Ludwig © CORE 2016 73 der Stakeholder. Für die Dokumentation könnten die im Kapitel 3.1.2. „Das Konzept einer Architekturbeschreibung“ beschriebene Norm ANSI/IEEE 1471-2000 herangezogen werden. Der Entwurf der Architekturentscheidung könnte beispielsweise mit Hilfe der Architekturevaluationsmethode ATAM aus dem Kapitel 3.1.3. „Qualitätsanforderungen an eine Software-Architektur“ unter Berücksichtigung von konkreten Szenarien geprüft werden. Entscheidet sich ein Unternehmen für eine Big-Data- Lösung, so bildet die Einführung den Meilenstein, um aktuelle technologische Entwicklungen als Unternehmen mittragen zu können. Neue Technologien drängen in den Markt. Kognitive Systeme erlauben eine wesentlich einfachere Zusammenarbeit zwischen Mensch und Maschine. Sie reichen von Datenanalysen über natürliche Sprachverarbeitung bis hin zu Machine Learning. Auch das „Internet der Dinge“, also die intelligente Vernetzung von Geräten und Maschinen über das Internet wächst rasant an. Unternehmen werden zunehmend von der Möglichkeit profitieren, über vernetzte Geräte Ereignisse zu senden, zu empfangen, zu sammeln, zu analysieren und angemessen reagieren zu können. 75 Bachelor Thesis Corinna Ludwig © CORE 2016 73 IV Quellenverzeichnis [1] AltusInsight 2015. Lambda-Architektur. URL: https://www.altusinsight.de/lambda-architecture/data-ingestion/ [Stand 2016-09-23]. [2] Barkow Consulting 2016. German InsurTech in 18 Facts. URL: http://www.barkowconsulting.com/13-facts-about-german-insurtech-vc/ [Stand 2016-06-09]. [3] BITKOM 2012. Big Data im Praxiseinsatz - Szenarien, Beispiele, Effekte. URL: https://www.bitkom.org/Publikationen/2012/Leitfaden/Leitfaden-Big-Data-im-PraxiseinsatzSzenarien-Beispiele-Effekte/BITKOM-LF-big-data-2012-online1.pdf [Stand 2016-08-11]. [4] BITKOM (2014). Big-Data-Technologien-Wissen-für-Entscheider: Leitfaden. URL. https://www.bitkom.org/Publikationen/2014/Leitfaden/Big-Data-Technologien-Wissen-fuerEntscheider/140228-Big-Data-Technologien-Wissen-fuer-Entscheider.pdf [Stand 2016-0811]. [5] Boehm B. 2012. Biography: TRW Professor of Software Engineering, Computer Science Department Director. URL: http://sunset.usc.edu/Research_Group/barry.html [Stand 201606-16]. [6] Büst R.; Hille M & Schestakow S. (2015). Digital Business Readiness: Wie deutsche Unternehmen die Digitale Transformation angehen. URL: https://www.crisp-research.com/publication/digital-business-readiness-wie-deutsche-unternehmen-die-digitale-transformationangehen/ [Stand 2016-06-16]. [7] Schön C. (2015). Wie Metadaten Big Data beherrschbar machen. URL: https://bigdatablog.de/2015/05/05/wie-metadaten-big-data-beherrschbar-machen/ [Stand 2016-08-10]. [8] COREtechmonitor (2016). InsureTechs Database. tor.com/insuretechs-database/ [Stand 2016-09-25]. URL: http://www.coretechmoni- [9] deutsche-startups.de (2016). InsurTech: Die Mega-Übersicht für Deutschland. URL: http://www.deutsche-startups.de/2016/04/27/insurtech-die-mega-uebersicht-fuer-deutschland/ [Stand 2016-06-09]. [10] Dördrechter N. (2016). Zukunft von InsurTech in Deutschland. Online im Internet: URL: http://www.oliverwyman.de/content/dam/oliver-wyman/europe/germany/de/insights/publications/2016/jul/Oliver_Wyman_Policen%20Direkt_Insurtech-Radar.pdf [Stand 2016-0916]. [11] GDV (2015a). Die Geschichte der Datenanalyse. URL: http://www.gdv.de/2015/11/infografik-die-geschichte-der-datenanalyse/ [Stand 2016-09-15]. [12] GDV (2015b). So suchen die Deutschen im Internet nach Versicherungen. URL: http://www.gdv.de/2015/03/so-suchen-die-deutschen-im-internet-nach-versicherungen/ [Stand 2016-09-16]. [13] GDV (2015c). Warum Versicherer Daten brauchen. URL: http://www.gdv.de/2015/11/warum-versicherer-daten-brauchen/ [Stand 2016-09-15]. [14] GDV (2016). Besser versichert durch präzisere Daten. URL: http://www.gdv.de/2016/07/besser-versichert-durch-praezisere-daten/ [Stand 2016-09-16]. [15] GruenderSzene (2016a). Insurtech – oder wie Startups Versicherungen modernisieren. URL: http://www.gruenderszene.de/allgemein/insurtech-swiss-innovation-outpost-20153514 [Stand 2016-06-09]. [16] GruenderSzene (2016b). Insurtech – oder wie Startups Versicherungen modernisieren. URL: http://www.gruenderszene.de/allgemein/insurtech-swiss-innovation-outpost-20153514 [Stand 2016-06-09]. [17] Heinrich G., (2007). Allgemeine Systemanalyse. München: Oldenbourg. (Wirtschaftsinformatik kompakt). URL: http://deposit.d-nb.de/cgi-bin/dokserv?id=2923164&prov=M&dok_var=1&dok_ext=htm. [18] IfD Allensbach (2015). Versicherungen - Besitz einer Hausratversicherung in Deutschland 2015 | Statistik: Allensbacher Markt- und Werbeträger-Analyse - AWA 2015. URL: 76 Bachelor Thesis Corinna Ludwig © CORE 2016 73 http://de.statista.com/statistik/daten/studie/266295/umfrage/versicherungen--besitz-einerhausratversicherung-in-deutschland/ [Stand 2016-06-08]. [19] Internap (2014). Decoding Big Data Infrastructure Decision: Data in Motion, Data at Rest. URL: http://www.internap.com/internap/wp-content/uploads/2014/12/Data_InMotion__VS_atRest_840px_2.jpg [Stand 2016-08-10]. [20] Kerr R. (2013). Schema on Write vs. Schema on https://www.youtube.com/user/MSBIAcademy/about [Stand 2016-08-28]. Read. URL: [21] Khaki S. (2016). Big Data : Concepts, Challenges and Solutions. URL: http://bigdatatech.blogspot.de/p/big-data-definitions-and-concepts.html [Stand 2016-09-17]. [22] Kreps J. (2013). The Log: What every software engineer should know about real-time data’s unifying abstraction. URL: https://engineering.linkedin.com/distributed-systems/log-whatevery-software-engineer-should-know-about-real-time-datas-unifying [Stand 2016-09-24]. [23] Kreps J. (2014). Questioning the Lambda Architecture. Staff Engineer LinkedIn. URL: https://www.oreilly.com/ideas/questioning-the-lambda-architecture [Stand 2016-09-13]. [24] Marcous, D. (2015). Big Data Real Time Architectures. Data Wizard at Google. URL: http://www.slideshare.net/DanielMarcous/big-data-real-time-architectures-51967547 [Stand 2016-09-12]. [25] Gualteri M. (2013). Big Data prediction for 2013. URL: http://blogs.forrester.com/mike_gualtieri [Stand 2016-08-07]. [26] Museum der deutschen Versicherungswirtschaft (2007). Historisches ab 1750 v.Chr. URL: http://www.versicherungs-geschichte.de/en/historisches-ab-1750-vchr.html [Stand 201606-08]. [27] Mysore D. (2013) Introduction to big data classification and architecture. URL: https://www.ibm.com/developerworks/library/bd-archpatterns1/. [28] Prognos (2013). Die Bedeutung der Versicherungswirtschaft für den Wirtschaftsstandort Deutschland: Im Auftrag des GDV. URL: http://www.gdv.de/wp-content/uploads/2013/10/GDV_Prognos_Studie_Bedeutung_der_Versicherungswirtschaft_fuer_Deutschland_2013.pdf [Stand 2016-06-08]. [29] Rudolf B. (2016). Vertrieb der Zukunft: Fintechs greifen nach der Schnittstelle zum Kunden. (06).: URL: http://www.versicherungsmagazin.de/Artikel/196/24697/Vertrieb-der-ZukunftFintechs-greifen-nach-der-Schnittstelle-zum-Kunden.html [Stand 2016-02-06]. [30] Statisisches Bundesamt (2010). Anteile starker Branchen am Bruttoinlandsprodukt in Deutschland 2010 | Statistik. URL: http://de.statista.com/statistik/daten/studie/262361/umfrage/anteile-starker-branchen-am-bruttoinlandsprodukt-in-deutschland/ [Stand 2016-0608]. [31] Süddeutsche.de GmbH, Munich & Germany (2014). Versicherungen – Allianz setzt alles auf die digitale Karte. URL: http://www.sueddeutsche.de/geld/versicherungen-allianz-setzt-alles-auf-die-digitale-karte-1.2141052 [Stand 2016-06-08]. [32] Versicherungsbote (2014). Versicherungsvertrieb: Google oder Amazon könnten zu echter Konkurrenz werden. URL: http://www.versicherungsbote.de/id/4808683/Versicherungsvertrieb-Google-Amazon/ [Stand 2016-09-16]. [33] Versicherungsforen (Leipzig 2014). IT für Versicherungen - steigende Anforderungen, steigende Relevanz. URL: http://www.versicherungsbote.de/id/4807710/Versicherung-IT-Versicherungsforen-Leipzig/ [Stand 2016-09-15]. [34] Versicherungsmagazin (2016). Ergo baut um und Stellen ab - versicherungsmagazin. URL: http://www.versicherungsmagazin.de/Aktuell/Nachrichten/195/23145/Ergo-baut-um-undStellen-ab.html [Stand 2016-06-08]. [35] Wedekind K., Dormann B.; Lay U. (2016). „Digitalisierung in der Versicherungsbranche. Treiber für den neuen Zeitgeister – Ansätze, Fragen und Lösungen“. URL: http://blog.versicherungsforen.net/2016/05/kunden-und-digitalisierung-treiben-die-assekuranz/ [Stand 2016-06-08]. 77 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Autorin Corinna Ludwig ist Student Professional bei CORE. Neben ihres Studiums in Wirtschaftsmathematik unterstützt sie Projektteams bei der Umsetzung umfangreicher IT Transformationen. Ihren fachlichen Schwerpunkt im Anforderungsmanagement untermauert sie mit ihrer Abschlussarbeit zu Big Data Architekturmodellen in der Versicherungsindustrie. 78 Bachelor Thesis Corinna Ludwig © CORE 2016 73 Über das COREinstitute Das COREinstitute ist eine Denkfabrik zur Erforschung der Dynamik und Systematik technologisch getriebener Transformationen in Industrien mit einem hohen Anteil an IT im Wertschöpfungsprozess. Um den Wandel aus Technologie zu gestalten, analysieren wir Ursachen und Wirkmechanismen komplexer IT-Transformationen und entwickeln gemeinsam mit Entscheidern aus Wirtschaft, Politik und Wissenschaft Lösungsansätze. Die Resultate unserer Forschung stellen wir einer breiteren Öffentlichkeit im Rahmen von übergreifenden Publikationen, Einzelstudien sowie Vorträgen zur Verfügung. http://institute.core.se/home/ Disclaimer Die abgebildeten Logos stehen im Eigentum der jeweiligen Unternehmen. Die COREtransform GmbH hält keine Rechte an den Logos und nutzt diese ausschließlich zu wissenschaftlichen Zwecken. Die Erklärung an Eides statt für diese Arbeit wurde im Rahmen des Studienabschlusses vom Autor an die Uni geleistet. Das Urheberrecht verbleibt beim Autor. Die COREtransform GmbH übernimmt keine Haftung für Verstöße gegen das Urheberrecht oder sonstige fahrlässige Zuwiderhandlungen des Autors im Zusammenhang mit der Abschlussarbeit. 79 Bachelor Thesis Corinna Ludwig © CORE 2016 73 COREinstitute CORE SE Am Sandwerder 21-23 Am Sandwerder 21-23 14109 Berlin | Germany 14109 Berlin | Germany https://institute.core.se https://www.core.se Phone: +49 30 26344 020 Phone: +49 30 26344 020 [email protected] [email protected] COREtransform GmbH COREtransform GmbH Am Sandwerder 21-23 Limmatquai 1 14109 Berlin | Germany 8001 Zürich | Helvetia https://www.core.se https://www.core.se Phone: +49 30 26344 020 Phone: +41 442 610 143 [email protected] [email protected] COREtransform Ltd. COREtransform MEA LLC One Canada Square DIFC – 105, Currency House, Tower 1 London E14 5DY | Great Britain Dubai P.O. Box 506656 I UAE https://www.core.se https://www.core.se Phone: +44 203 319 0356 Phone: +971 4 3230633 [email protected] [email protected] 80 Bachelor Thesis Corinna Ludwig © CORE 2016
