IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

BI-Tool Marke Eigenbau: prähistorisches Altertum oder agile Avantgarde?

Kategorie: Trend-Tools

„Beim BI-Frontend haben wir die Wahl zwischen zwei etablierten Anbietern, aber eigentlich wollen wir was Eigenes. Können wir mal Eure Einschätzung hören? Wir überlegen sogar ob wir selber etwas bauen sollen“ lautete die Ansage der IT-Projektleitung eines unserer Kunden. „Nicht euer Ernst“, dachte ich mir dazu. Immerhin steckten wir nicht mehr in den späten 90ern als Management-Informationssysteme gerade zu großen modernen BI-Landschaften umgebaut wurden, sondern schrieben das Jahr 2015. Und trotzdem – Anfang 2016 ging dieses Tool tatsächlich live.

Die Marktsituation für BI-Tools ist – mal abgesehen von einem Konzern mit festen Architekturvorgaben – nicht mehr so klar wie noch vor wenigen Jahren. Im Kielwasser von Big Data Analytics, dem Data Lake und anderen Überlegungen, die klassische Architekturen und Konzepte in Frage stellen, wirft auch das Berichtswerkzeug folgende Überlegung auf: Ist „Buy“ immer der Weisheit letzter Schluss oder kann auch manchmal „Make“ der Schlüssel sein – auch wenn es zunächst unorthodox scheint?

Die Anforderungen des Kunden waren auf den ersten Blick so klassisch, dass sie uns eigentlich zur Wahl eines klassischen Reporting- und Analysetools hätten führen müssen – keine Raketenwissenschaft, sondern eher Standardumfang und State of the Art bei Werkzeugen zur Berichterstattung. Wichtig waren aber zwei nicht-funktionale Anforderungen:

  1. Die Anwendung sollte Informationen für „Kundeskunden“ bereitstellen und zu diesem Zweck in die Webseite eingebunden werden. Damit entfiel auch die Möglichkeit, das Tool in die Berechtigungslandschaft einzubinden und die dazu verfügbare Architektur einfach weiter zu verwenden.
  2. Das Layout sollte exakt zur Webseite und Corporate Identity Des Kunden passen, sodass es für Anwender nicht ersichtlich ist um welches Tool es sich handelt.

Lücken schließen mit einer selbstgebauten Reporting-Lösung

Diese Anforderungen gaben schließlich dem Eigenbau den Vorzug, da ein Tool von der Stange diese Bedingungen nur mit sehr aufwändigem Customizing erfüllen kann. Die Anpassbarkeit der Oberfläche der im Konzern verfügbaren BI-Suites ist nur gering und die Gefahr nicht unerheblich, dass bei künftigen Migrationen dadurch hohe Kosten entstehen. Weil sich ein eingekauftes BI-Standardtool nicht ohne weiteres im Internet bereitstellen lässt, hätten für Authentisierung und Autorisierung zusätzliche Architekturkomponenten eingesetzt werden müssen.

REST API zum Datenaustausch: ein Beispiel starker Standardisierung

Wie aber baut man nun ein modernes, performantes und attraktives BI-Tool, ohne über das Budget der großen BI-Hersteller zu verfügen? Man beschränkt sich auf wesentliche Funktionsbausteine, vereinfacht soweit möglich, und kombiniert geschickt viele Räder, die bereits erfunden wurden. Geschickt bedeutet hier: etablierte Standards aus Web- und BI-Entwicklung wählen, die gut zusammenpassen. Das BI-Rad wurde also – trotz „Make“ – mitnichten neu erfunden, sondern lediglich neu zusammengesteckt.

 

Architektur der Anwendung. An die REST Schnittstelle können auch weitere Anwendungen angebunden werden.

 

Eine REST-Schnittstelle stellt die Daten in einer API bereit. Damit können in Zukunft auch weitere Abnehmersysteme mit Daten versorgt werden, die iOS App ist nur eines von vielen denkbaren Beispielen. Das Frontend verwendet aktuelle JavaScript-Komponenten, generische BI-Funktionalitäten werden vom Java Application Server bereitgestellt. Nach wenigen Wochen stand bereits der Prototyp auf Basis des Data Warehouse, nach einem guten halben Jahr ging die erste Version in Produktion. Nicht in einem Startup wohlgemerkt, sondern in einem großen Konzern.

Stärken der Eigenentwicklung nutzen

Da unser Java Server Backend die Daten in einer standardisierten Schnittstelle bereitstellt, können perspektivisch weitere Anwendungen angeschlossen werden – noch ein positiver Nebeneffekt. Dabei ist es künftig auch vorstellbar, die Dateninhalte der Anwendung zu monetarisieren, für die Zusammenarbeit mit anderen Unternehmen weiterzuverwenden oder den Kunden unseres Kunden wieder über eine API-Datenzugänge anzubieten. Die unmittelbare Stärke ist jedoch: das Tool ist exakt auf die Bedürfnisse der Anwender zugeschnitten und damit ein großes Pfund für unseren Kunden. Er kann wiederum seinen Kunden nun als zusätzliches Gimmick einen Zugang zu einer passenden Reportinglösung in Ergänzung zu seinen Produkten anbieten.

Agile Entwicklung als Katalysator

Durch den geschickten Aufbau aus fertigen Komponenten der modernen Webentwicklung mit Standardschnittstellen und bewähren Methoden entstand in kürzester Zeit ein maßgeschneidertes BI-Tool, das viele Features einer BI-Anwendung umsetzt. Die Kosten blieben dabei im Korridor und vergleichbar mit einem mit viel Aufwand individuell angepassten klassischen BI-Tool. Katalysator für den Erfolg waren dabei insbesondere auch das agile Vorgehen und die Zusammenarbeit in einem Team mit Kollegen beim Kunden. Für die Endkunden ist es eine große Erleichterung im Arbeitsalltag, oder informell: „richtig lässig“.

Was denken Sie – geht der Trend tatsächlich wieder zu mehr „Make“ statt „Buy“? Oder eher eine Art „Best of“ aus bestehenden Komponenten wie im vorliegenden Fall beschrieben?

Über den Autor

Alexander Mendle
Alexander Mendle
Agile BI, DWH Automation, sowie innovative Ansätze wie Data Vault sind mein Steckenpferd. Als Architekt und Scrum-Master setze ich solche Konzepte für unsere Kunden in Wert.
Nice article. As mentioned most of customers are using more of BigData ( Haddop, Datalake ,etc..) to boost BI reporting tools. I also think re-usable components way to go.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.