27. März 2019

DevOps – Modeerscheinung oder echter Mehrwert

Die IT ist seit jeher ständigen Veränderungen unterworfen. Anforderungen von Kunden und der Wunsch nach schneller Umsetzung und Einführung von neuen „Features“ wachsen von Tag zu Tag. Diese Wünsche der Kunden stehen in einem Gegensatz zu den klassischen Ansätzen der IT, in denen neue Releases teils monate- oder gar jahrelang im Voraus geplant werden. Zum Teil werden damit auch Anforderungen umgesetzt, welche bei Einführung schon wieder veraltet sind. Die IT ihrerseits versucht auf diese Herausforderung mit neuen Entwicklungsmethoden zu reagieren. So wird bereits in vielen Projekten der klassische Ansatz des Wasserfallmodells durch den Ansatz der agilen Softwareentwicklung ersetzt. Ziel dabei ist es, eine Software mit geringem bürokratischen Aufwand schnell und qualitativ hochwertig zu erstellen und stetig weiter zu entwickeln. Diese Vorgehensweise führt allerdings zwangsläufig zur nächsten Herausforderung, diese Software jederzeit fehlerfrei bereitstellen zu können. DevOps (Development & Operations) greift genau diesen Punkt auf und adressiert die Verzahnung zwischen agiler Entwicklung und zeitnaher Bereitstellung der Software.

DevOps - was steckt genau hinter dem Begriff?

Mittlerweile gibt es verschiedene Definitionen, die den Begriff DevOps beschreiben. Gemein ist aber allen das gemeinsame Ziel: Eine schnelle und stabile Bereitstellung von qualitativ hochwertiger Software. Hierzu möchte DevOps für eine effizientere und effektivere Zusammenarbeit der Bereiche „Development“, „IT Operations“ und „Qualitätssicherung“ beitragen. Zum Einsatz kommen dabei die unterschiedlichsten Tools, welche diesen neuen Ansatz unterstützen sollen. Man könnte nun meinen, durch den einfachen Einsatz einiger neuer Tools im Bereich der Codeverwaltung, des Test- und Change-Managements und des Monitorings wäre eine Einführung von DevOps zwangsläufig erfolgreich. Eine solche Interpretation wäre aber bereits der Beginn des Scheiterns einer DevOps – Einführung. Sicherlich haben all diese Werkzeuge ihre Berechtigung, jedoch sollten sie nur als Mittel zum Zweck angesehen werden. Eine Diskussion über eine Einführung sollte sich niemals nur auf den technologischen Teil beschränken. Denn einem Mitarbeiter ist es nur schwer zu erklären, warum sich Technologien, die jahrelang erfolgreich benutzt wurden, nun plötzlich durch einen neuen „unerprobten“ und ähnlich aufwendigen Prozess ersetzt werden, wenn man ihm das Ziel im Ganzen nicht vor Augen führen kann.

Einführung im Unternehmen

Eine erfolgreiche DevOps – Einführung ist folglich gebunden an das Verständnis der Mitarbeiter für den dahinter stehenden Mehrwert. Man könnte gar sagen, es benötigt einen Kulturwandel innerhalb eines Unternehmens. Denn seit jeher stehen die Ziele von Entwicklern und IT Operations in einem Gegensatz. Während Entwickler bestrebt sind durch häufige Releases neue Features möglichst schnell verfügbar zu machen, steht für Operations ein stabiles System im Vordergrund. Neue Funktionen bringen aus Sicht von Operations zunächst nur ein erhöhtes Ausfallrisiko mit sich. Wichtig ist es also diese individuellen Ziele zu einem gemeinsamen Ziel zu koordinieren. Es erfordert Verständnis für einander und echtes Team-Work zwischen Entwicklung und Operations.

Es wird sich zeigen, dass nicht alle Vorteile direkt nach einer DevOps-Einführung zum Tragen kommen. Oftmals benötigen die Teams Zeit sich von alten Gewohnheiten zu lösen und sich an die neuen Prozesse zu gewöhnen. Vermehrt wird man feststellen, dass bei der Einführung nicht alles perfekt läuft und es sowohl gedanklich als auch technologisch Verbesserungspotential gibt. Durch kontinuierliche und schrittweise Verbesserungen lässt sich DevOps aber langfristig zum großen Vorteil im Unternehmen nutzen.

10. September 2018

„Data Warehouse“ ist out. Brauchen wir jetzt einen „Data Lake“?

 

Die technisch gereifte Möglichkeit, Unmengen von Daten im Unternehmen speichern und verarbeiten zu können, hat den Fokus auf das reine Sammeln von Daten verschoben. Auch die Möglichkeit, völlig unterschiedliche Typen von Daten (strukturiert und unstrukturiert) ablegen zu können und die gelebte Praxis, geschäftliche Analysen dieser Daten auf „später“ zu verschieben, hat zu dieser Entwicklung beigetragen. Wir sammeln also auf Teufel komm raus alles, was irgendwie von Nutzen sein könnte, legen es in einem „Data Lake“ ab und hoffen darauf, dass eines Tages daraus ein Mehrwert für das Unternehmen entsteht.

So sehr es wünschenswert ist diese Data Lakes zu etablieren, um potentiell wertvolle Informationen zu sichern, so sehr ist es aber auch notwendig, den Fokus wieder deutlicher auf die Analyse dieser Daten zu lenken. Erst diese Analysen erlauben es, geschäftliche Erkenntnisse für das Unternehmen zu gewinnen und damit Mehrwert zu schaffen. „Big Data“ ist insofern auch nur ein weiteres Buzzword um zu signalisieren, dass wir dies nun auch aus sehr großen, ggf. unstrukturierten und laufend aktualisierten Datenmengen können.

Analyse selbst soll von den vermeintlich überall verfügbaren Data-Science-Fachkräften gemacht werden. Diese tatsächlich sehr raren, hochspezialisierten Daten-Spezialisten sollen in der Lage sein, aus den Unmengen an ungeschliffenen Rohmaterial von Daten wertvolle Erkenntnisse zu schürfen. Sie schaffen das allerdings nur, wenn sie unstrukturierten Daten eine Struktur geben, wenn also die Daten aus ihrer Rohform in eine für intelligente Verarbeitung und Geschäftsanalyse verarbeitbare Form transformiert werden. Das ist ein hochkomplexer und sehr aufwändiger Vorgang, der oftmals mehr Kapazitäten bindet, als die eigentliche Analyse selbst. Wir haben sogar wieder ein Buzzword dafür etabliert: „Schema-on-read“, und viele halten es plötzlich für den Königsweg. Tatsächlich ist es aber nur eine sinnvolle Erweiterung der lange bekannten Architektur, die jetzt als das „klassische“ Data Warehouse bezeichnet wird. Eigentlich hat man nur erkannt, dass es sinnvoll ist, entsprechend ausgebildeten Daten-Spezialisten auch Zugriff auf Rohdaten zu geben. Der vermeintlich alte Ansatz „Schema-on-write“ hat aber unverändert seine Berechtigung und ist, vielmehr noch, im Kern unverzichtbar. Einmal gewonnene Erkenntnisse, geschäftliche Grundstrukturen und Zusammenhänge sollten von allen Anwendern im Unternehmen einfach nutzbar sein. Das erfordert ein Datenmodell, welches diese Zusammenhänge transparent macht. Es ist schlichtweg ineffizient die Schaffung dieser Grundstrukturen immer wieder aufs Neue, und damit hochredundant, jedem Data Scientist oder Analysten als notwendige Datenvorbereitung aufzuerlegen.

Eine effiziente und wirklich Mehrwert schaffende Informationsinfrastruktur berücksichtigt das alles und sieht hinter den Buzzwords Data Lake, Big Data etc. das, was sie sind: Sinnvolle Erweiterungen des „klassischen“ Data Warehouse um neue Arten der Datennutzung und Datenspeicherung, ergänzt um weitere Skalierungseffekte durch neue Arten der Datenverarbeitung. Wenn wir so wollen: Lasst uns das Data Warehouse weiterentwickeln und alles, was Data Lake, Big Data und Co. an neuen Möglichkeiten bringen für eine gesamthaft effiziente Informationsinfrastruktur im Unternehmen nutzen. Man könnte dafür natürlich auch wieder ein neues Buzzword erfinden und dieses Kunstwerk Information Bridge nennen 😉

© 2019 | Information Bridge, Gesellschaft für Informationsanalyse mbH | Impressum