Einführung
Die Verwaltung der BI Architektur benötigt Informationen verschiedener technologischer Bereiche der ganzen IT Abteilung. So sind nebst den klassischen ETL Prozessen verschiedene BI Elemente, meist mehrere Datenbanken mit unterschiedlichen Datenmodellen, wie auch Portal Applikationen und spezifische Client Software involviert.
Auch bei «normalen» Applikationen mit einfacherer Struktur ist es immer empfehlenswert, eine Architekturübersicht als Teil des «Operation Handover» erstellen zu lassen. Bei BI Lösungen wird dies wegen der oben erwähnten Komplexität umso wichtiger. Eine solche Architekturkarte der BI Landschaft ist auch deshalb sinnvoll, weil sie unsere Arbeit beim Kunden transparent macht und zudem die Qualität der Änderungen an dieser Architektur besser gewährleistet. Ein Bild sagt auch hier mehr als tausend Worte!
In diesem Blog präsentiere ich ein Template basierend auf meinen Erfahrungen. Er zeigt die Architektur auf, erklärt ihre Komponenten und wie und wo sie die Arbeit des BI Infrastruktur Architekten sowie der Administratoren erleichtert:
Das Template basiert dabei auf einer klassischen BI Portal Architektur, in welcher ETL und BI Portal Applikationen von SAP benutzt werden.
Analytische BI Komponenten werden oft noch gar nicht als BI wahrgenommen und separat behandelt und daher aus IT Sicht zu wenig standardisiert.
Ein wichtiges Ziel der BI Strategie sowie der BI Architekten sollte deswegen sein, die zersplitterte BI Architektur, welche sich oft in mehreren parallelen Aufbauten mir dedizierten Servern und Infrastrukturelementen darstellen, wieder zu vereinen. So werden Kosten gespart, die Investitionen geschützt und Service Qualität gewährleistet. Wir werden das in einem separaten Blog behandeln.
In dieser Landschaft müssen zwei grundsätzliche Bereiche unterschieden werden:
- Kern-Elemente beinhalten die Infrastruktur Assets, die für die Wertschöpfung des BI Prozesses direkt zuständig sind.
- Beschreibungs-Elemente geben wertvolle Zusatzinformationen bezüglich der Betreuung der Architektur und werden in weitere Kategorien unterteilt. Dies, um die Navigation zu vereinfachen und um diese kontextuellen Informationen je nach Bedarf auch einfach ausblenden zu können.
Kern-Elemente
Unser Template folgt der Grundregel der Periodentabelle bei den Positionen der verschiedenen Kern-Elemente. So wird die Wichtigkeit bei den meisten Fällen ähnlich dargestellt; sprich: Produktive Server sind auf End-Benutzern ausgelegt und werden darum an der unteren rechten Ecke positioniert.
Diese Methodik sortiert die Elemente entlang der zwei wichtigsten Prozesse:
- Release Prozess. Enthält meistens die Umgebungen Development, Test und Produktion. UAT, Sandbox, sowie Urgent Umgebungen kommen manchmal auch zum Einsatz:
- Urgent Umgebung machen im ETL Bereich durchaus Sinn
- UAT und Testumgebung kann für ETL meistens auf demselben Server gehostet werden. Dafür sind aber auch in diesem Bereich mehrere Server empfohlen (je nach Anzahl aktive Release Linien)
- Eine Sandbox Umgebung kommt meistens in Frontendbereich zum Einsatz, da sie hier als PoC für neue Technologien verwendet wird
- Datenfluss. Er bildet den operativen Prozess ab. Daten aus einem oder mehreren ERP Systemen, sowie aus generischen Interfaces, werden mit Hilfe von ETL Tools abgearbeitet und für Frontendtools bereitgestellt. Bei der klassischen BI handelt es sich dann um ein BI Portal. Aber schnell werden auch Frontend-Tools aus Client Umgebungen heraus verwendet.
Server sind hier der wichtigste Teil der Architektur. Alle massgebenden Informationen werden darin gleich für die einzelnen Maschinen aufgelistet:
In obigen Beispiel hat der Server 4 CPU Kerne, 16GB RAM und zwei Business Applikationen installiert: BO DS und BO IPS. Die Menge und Grösse verfügbarer Storage Mounts werden nicht aufgelistet, da dies nicht lizenzrelevant ist. Die aktuelle (also Real-Time) Kapazität ist hier wichtiger als die potenzielle.
Was aber zudem noch aufgelistet werden sollte sind die verschiedenen Interfaces für Daten Konsumation und Daten-Ziele. Diese Liste hilft bei der Visualisierung von Verknüpfungen zwischen den verschiedenen Elementen des ETL Prozesses, wie zum Beispiel Datenbank Instanzen oder Flat Files, falls solche verwendet werden.
Auf der oberen rechten Seite markieren wir die Art der Daten Security Methode(n):
In diesem Fall ist es ein Storage Level Backup, welches es ermöglicht, falls nötig, den Stand der logischen Storage Einheit wiederherzustellen.
Datenbankserver werden vereinfacht dargestellt:
Hier ist die Anzahl, Funktion und Bestimmung (aus BI Sicht) der einzelnen Datenbankinstanzen relevant. In einer typischen BI Architektur existieren nebeneinander dedizierte DB Instanzen für Systemdatenbanken, für STG (inkl. ODS) und für das DWH (inkl. DataMarts). Die benötigte Anzahl STG-DWH Paare hängt zum grössten Teil von dem Bedarf des ETL Entwicklungs-Teams ab und davon, wie viele Release Linien parallel betrieben werden.
Nebst den einzelnen DB Instanz Namen ist es empfehlenswert, auch die Schema- und Benutzernamen anzugeben, welche dafür verwendet werden (die runden blauen Elemente).
Häufig verwendete Ports werden idealerweise gleich hier angegeben:
Sie können am besten am Rande der entsprechenden Sicherheits-Zone dargestellt werden, da die einzelnen Firewalls und/oder Regeln auch dementsprechend gruppiert sind.
Sicherheits-Zonen umfassen relevante Server und werden gut sichtbar auch mit dedizierten Farben dargestellt:
Das Konzept des Netzwerkes ist in der Regel auch auf den Release Prozess, sowie auf den Datenfluss ausgerichtet. Darum werden solche Architektur Karten meist zuerst durch das Netzwerk Team erstellt. Leider wird dann auch weniger Gewicht auf Informationen bezüglich Business Applikationen gelegt.
Andere Kern-Elemente werden unten links abgebildet. Diese sind:
- Interne IT Services
- Client Umgebungen
Interne Services: Darunter verstehen wir IT Services, die den BI Kunden nicht direkt als Dienstleistungen, sondern als unterstützende Services angeboten werden, um SLA relevante Dienste gewährleisten zu können, wie zum Beispiel:
- File Transfer
- SMTP
- Monitoring
- Domain Management
Client Umgebungen: Fast immer ist es möglich, die Typen der verschiedene Terminal Services sowie der Workstation Konfigurationen gemäss den beiden Prozessen darzustellen.
Somit gelangt das Konfigurieren und das Erzeugen durch das Entwicklungs-Team ganz nach oben und End-Benutzer Maschinen ganz nach unten, direkt neben dem produktiven Fronte-End BI Portal. Damit ist das Gesamt-Konzept von Asset Kritikalität bestens repräsentiert, da die Benutzer die wichtigsten Assets von jeder BI Lösung sind.
Mit dem obigen Element stehen einer Diskussion zwischen dem BI Architekten und dem Business, sowie zwischen verschiedenen Infrastruktur Teams (Server, Netzwerk, Security, Operation sowie Desktop Engineering) nichts mehr im Weg.
Die Karte bietet aber noch mehr Informationen, um die Arbeit der BI Architekten zu unterstützen. Diese werden wir im folgenden Beitrag genauer unter die Lupe nehmen.
Beschreibungs-Elemente
Legende
Hier sollen einzelne Symbole der Architektur erläutert werden. Wie bei allen Arten von Karten helfen sie Personen, die die Architektur Karte noch nicht kennen, die einzelnen Zeichnungen schnell zu interpretieren und auch ohne zusätzliche Erklärungen zu verstehen.
Darum ist es bedeutsam und wichtig, dass diese Karte auf einem gesicherten Netzwerk-Share oder einer MGMT-Site allen Teams und Kollegen zur Verfügung gestellt wird. So können Anfragen, welche Server denn nun hochgestuft werden sollen oder welche Datenbanken betroffen sind, sofort beantwortet werden. Zudem kann damit ein gemeinsames Verständnis von Terminologie und Architektur gewährleistet werden.
Kontakte
Wir unterscheiden zwischen zwei Arten von Stakeholdern: Business und IT. Beide sind gleichermassen wichtig für unsere Arbeit an der Architektur. Natürlich ist es so, dass die Kollegen aus der IT Abteilung den grössten Teil der Arbeit im Zusammenhang mit der Architektur leisten werden, wie etwa Installationen von neue Servern oder Upgrades auf neue Produktversionen. All diese Elemente sind aber dazu bestimmt, den Mehrwert für das Business zu erhöhen und müssen daher möglichst transparent kommuniziert und dargestellt werden. Nicht alle Kollegen aus den Business Abteilungen müssen immer jedes Element verstehen können. Aber wenn Business und IT solche Änderungen diskutieren, muss der aktuellste Stand gut visualisiert bereitstehen. So wird wiederum ein gemeinsames Verständnis bezüglich Terminologie und Assets eine fruchtbare Diskussion ermöglichen.
Dieses Verständnis wird durch die Verwendung von Layers zudem unterstütz, die es uns ermöglichen, irrelevante Informationen innerhalb von Sekunden auszublenden.
Für den BI Architekten selbst sind die aktuellen Kontakte aus IT und Business genauso wichtig wie die Ports, die man in der Firma verwendet. Diese Informationen sollten immer aktuell und gleichzeitig verfügbar sein.
Dabei können sogar technische Bezeichnungen der individuellen Teams zur Verständlichkeit beitragen. Sie werden oft im Ticketing sowie in internen Kommunikations-Systemen verwendet (z.B. welchem Team muss das Incident-Ticket geschickt werden, damit es möglichst schnell abgearbeitet wird).
Ports
Die einzelnen Ports ändern sich für gewöhnlich selten innerhalb einer etablierten Umgebung. Sie werden aber oft in der Suche nach Firewall- und Kommunikationsfehler einbezogen und enthalten zuweilen spezielle Berechtigungen.
Mit einer aktuellen Liste aller wichtigen Ports, sind der BI Architekt und die Administratoren für solche Situationen bestens gerüstet. Vor allem aber immer dann, wenn die Zeit gekommen ist, die Firewall Regeln aufzuräumen oder Gruppen für diese zu erstellen.
Die Visualisierung der Verbindungen hilft auch beim Changemanagement, damit keine Assets aus diesen Regeln vergessen gehen.
Lizenzen
Lizenzen zeigen uns die Grenzen auf innerhalb welcher unsere Kapazität sich bewegen kann und darf. Diese Information, kombiniert mit der Anzahl von Servern sowie der Menge ihre CPU und RAM, verschafft uns in kürzester Zeit einen Überblick, ob die Lizenzen gut genutzt werden. Und es zeigt auf, ob es Möglichkeiten gibt, die momentan verfügbare Kapazität ohne zusätzliche Lizenzkosten zu steigern.
Dies ist nicht nur während einer regulären Kapazitätsplanung hilfreich und einsetzbar, sondern auch beim Upgrade von Projekten und in Diskussionen bezüglich Performance Engpässen. Letztere sind ein häufiges Thema im BI Bereich und man kann davon ausgehen, dass diese bei einem gut frequentierten System jedes Quartal wiederkehren.
Dementsprechend kann man hier nicht nur Lizenzen der jeweiligen ETL- und BI Portal Software auflisten, sondern auch die von internen IT Services Assets. Und nicht zu vergessen: VMware, Oracle oder Citrix Lizenzen, falls diese in der Firma nur in begrenzte Anzahl zur Verfügung stehen.
Hardware Information
An dieser Stelle sollte man Spezifikationen der physischen Hardware auflisten, welche für die virtuellen oder dedizierten Maschinen verwendet werden. Es sind selten verwendet Informationen und sie werden daher nur an dem äusseren Rahmen der Architektur dargestellt.
Hilfreich sind diese besonders in einer Kapazitätsplanung und während typischen LCM Projekten (wie etwa Applikationsupgrades), da diese Informationen meistens schwer auffindbar sind.
Data Center Information
Falls die physischen Maschinen auf mehrere Orte verteilt sind, lohnt es sich meist, sich einen Überblick zu verschaffen, wo dieser Orte genau sind und nach welcher Logik diese Maschinen aufgeteilt wurden. Hier kann man jedoch nicht immer genau sagen, wo sich eine bestimmte Maschine zu einem bestimmten Zeitpunkt befindet, da sich der Ort durch vMotion dynamisch ändern kann. Aber fast immer kann man sagen, wo der Primary und Secondary Node platziert ist.
Dies ist äusserst hilfreich bei der Kapazitätsplanung und der Performance Analyse des Netzwerkes. Während man den Disaster recovery plan testet (was man jährlich tun sollte!) und während Incidentes, die der Kategorie Disaster zugehören, kann man auf diese Data Center Informationen ebenso kaum verzichten.
Verwaltung des Architektur Maps
Die oben beschriebene Anordnung der Elemente auf einer Architektur Karte ermöglicht eine personalisierte View und falls notwendig einen Ausdruck derselben.
Die Sichtbarkeit einzelner Elemente, Gruppen und Kategorien kann mit Hilfe von „Layers“ in MS Visio gesteuert werden:
Nebst den oben bereits aufgezählten Gruppen von Beschreibungselementen können noch folgende Gruppierungen nützlich sein:
BI Area: Falls diese Area eine Segregation auf Infrastruktur- bzw. Architekturebene erzeugt, wie zum Beispiel: Analytics, Standard BI oder nach Business Funktion: Finanzen, Konsolidation, usw.
ETL Workflows: Je nach Komplexität des ETL Prozesses kann es erwünscht sein, dass er in der Architektur reflektiert wird. Solche Fälle sind in der Regel sehr spezifisch und werden massgeschneidert auf der Karte integriert, so dass involvierte Infrastruktur Elemente gut erkennbar sind (z.B. komplexe generische Interfaces, Datenquellen oder -ziele ausserhalb der aufgeführten Standard BI Datenbanken.
Solche Fälle sind natürlich nicht ideal aus Sicht der BI Strategie und der BI Architekten. Aber diese Karte muss in erster Linie die Realität reflektieren und nicht frühere Visionen. Sie soll einerseits auch als Grundlage für architektonische Entscheidungen dienen und andererseits das Vertrauen der Benutzer aufbauen und vertiefen. Letztere sind nämlich natürlicherweise skeptisch gegenüber Entscheidungen, für die sie fachlich wenig Verständnis haben und welche zudem auch noch Ihre vertrauten Assets nicht korrekt darstellen.
Management Sicht: Diese sollte in der Regel hier nicht sichtbar sein, da das Layout eine starke Vereinfachung der Architektur enthält und somit wertvolle Informationen für ein technisches Gespräch verbirgt. Aber daher ist es für eine Diskussion mit dem oberen Management umso mehr geeignet:
Die oben dargestellte Sicht ist auch ausgedruckt ideal, um darauf während Meetings Notizen zu machen. Sie kann natürlich je nach Bedarf beliebig mit zusätzliche Informationen ergänzt werden. Man muss dabei aber die Ebene der Diskussion berücksichtigen, damit Entscheidungsträger nicht mit (evtl. unnötigen) Informationen überflutet werden.
Aktualisierung
Diese Karte kann theoretisch in ein Infrastruktur Monitoring Dashboard umgewandelt und mit Live-Daten gefüttert werden. Der Aufwand wäre aber wesentlich grösser, als dafür ein statisches Dokument zu erstellen. Die benötigten Informationen existieren bereits in den meisten Firmen.
Für den BI Architekten ist daher der Aufwand zur Erstellung relative gering. Aber man erhält trotzdem eine Dokumentation, welche die am meisten verwendeten Elemente der BI Architektur kompakt darstellt.
Operative Dokumentationen werden dadurch nicht überflüssig. Aber diese Karte eignet sich auf natürliche Weise als Zwischenspeicher, in dem alle relevanten Änderungen eingetragen werden können, bis die Haupt-Dokumentation für ein Update reif ist. Und da letztere oft sehr aufwändig in der Erstellung sind, werden die involvierten Kollegen sich nicht nur freuen, eine hilfreiche Bild der Gesamtarchitektur zu haben, sondern auch eine viel grössere Chance darin sehen, dass diese auch regelmässig aktualisiert wird.