Moderne IT-Architekturen für analytische Use Cases stellen die Unternehmensziele in den Vordergrund

Die Definition einer Zielarchitektur, die nicht nur modernen Buzzwords folgt, sondern die Erreichung der Unternehmensziele unterstützt, kann nicht durch ein einzelnes Lösungsmuster erstellt werden, sondern muss spezifisch definiert werden.

Der Wandel in “datengetriebene Unternehmen” steht industrieübergreifend bei vielen Vorständen in den Strategiepapieren. Gleichzeitig ist die Bedeutung dieses Wandels auf die Personas in eben diesen Unternehmen und vor allem der Umgang mit Daten innerhalb eines Unternehmens stark verschieden.

Michi, 54 Jahre, Unternehmensführung, möchte verlässliche Daten, die eine breite Basis für Entscheidungen bieten und in Echtzeit, durch Self-Service Tools bereitgestellt werden. Zusätzlich sollen bestimmte Daten durch advanced Analytics Methoden angereichert und dadurch weitere Insights generiert werden.

Robin, 32 Jahre, Risk-Compliance, sieht die Gefahr von Verstößen gegen geltende Regulierung wie der DSGVO und gleichzeitig die Gefahr von Datenverlusten und unbefugten Zugriffen auf zentrale Datenspeicher.

Kim, 37 Jahre, IT & Enterprise Architektur Department, muss mit den steigenden Datenmengen zurechtkommen und dafür sorgen, dass die Daten sowohl für operative Systeme, als auch für Analytics und Reporting bereitstehen und gleichzeitig gegen fremde Zugriffe abgesichert sind.

Die teilweise konkurrierenden Ziele des schnellen & quellsystemübergreifenden Datenzugriffs, der gleichzeitig sicher, compliant und skalierend ist, sind nur schwer zu erreichen. Um dies zu schaffen, ist ein übergreifender Ansatz nötig, der nicht die Popularität von Architekturpatterns, wie z.B. dem des Data Lakes in den Vordergrund stellt, sondern die Business Strategie. Basierend auf dieser Strategie muss dann entschieden werden, ob sich Data Warehouse, Data Lake, Data Mesh, Data Fabric, ein anderes Architekturpattern oder eine Kombination der genannten Möglichkeiten am Besten zur Unterstützung der Strategie bei gleichzeitiger Beachtung der Governancevorgaben eignet.

PwC Vorgehen

Um eine Systemlandschaft zu schaffen, welche alle Personas bestmöglich unterstützt und diese vom Zielbild zur Implementierung zu führen, hat sich ein 5 schrittiger Ansatz etabliert, der mit der Zielbilddefinition startet, den Status-Quo berücksichtigt, basierend auf identifizierten Lücken eine Roadmap ableitet und diese Lücken in einem Implementierungsprojekt schließt. Da in der ersten Phase der strategischen Basis wichtige Weichen gestellt werden und gleichzeitig Schritt 2 bis 5 sehr unternehmensspezifisch sind, möchte ich in diesem Beitrag auf Schritt 1 der “Strategischen Basis” fokussieren.

Abbildung: Beispielhaftes Vorgehen

Ziele von Business & IT sowie Use Cases

Wichtigster Ausgangspunkt bei allen Entscheidungen sollten die definierten Ziele von Business und IT sowie die analytischen Use Cases der Fachbereiche sein.

Für diese Strategien sind die Anforderungen abzuleiten, welche diese Strategie mit sich bringt. Dies können z.B. “Cloud First” oder die Beschränkung auf bestimmte Ländergesellschaften sein. Auch laufende Initiativen wie Netzwerkumbauten oder Cloudmigrationenen sollen als Grundlage genommen und daraus Anforderungen, an das Zielbild definiert werden. Die Use Cases der Fachbereiche geben Hinweise auf die Struktur der zu verarbeitenden Daten, die Datenmenge, die Datenquellen sowie die Art der Verwendung.

Interne & Externe Einflüsse

Interne Einflüsse wie die vorhandenen Quellsysteme und deren Schnittstellen, die Art der Daten & Datenflüsse, organisatorische Rahmenbedingungen oder Länderkonstellationen haben genauso einen Einfluss auf ein architekturelles Zielbild, wie regulatorische Anforderungen, geänderte Kundenerwartungen oder technologische Trends. Auch hier sollten aus allen Einflüssen entsprechende Anforderungen an das Zielbild abgeleitet werden.

Outside-In View

Die Outside-In View ist ein Schritt, der dafür sorgt, dass auch moderne Architekturpatterns wie Data Meshs oder weniger bekannte Konzepte wie das einer Data Fabric oder eines Lakehouses berücksichtigt werden und nicht nur die Klassiker Data Warehouse, Data Lake, Micro Service und Virtualisierung. Da es gleichzeitig keine one-size-fits-all Lösung gibt, sollte man in den meisten Fällen auf eine individuelle Kombination der Architekturpatterns zurückgreifen.

Abbildung: Architektur mit Building Blocks

Basierend auf den gewählten Architekturpatterns sollte eine High-Level Architektur entstehen, die aus Building Blocks besteht und die im nächsten Schritt zu einer funktionalen Architektur verfeinert wird.

Funktionale Architektur

Die funktionale Architektur beschreibt die Fähigkeiten, die ein IT-System / eine IT-Plattform bereitstellen soll und ordnet diese Fähigkeiten den im vorherigen Schritt definierten Building Blocks zu.

Abbildung: Beispiel Funktionale Architektur

Es wird dabei nicht unterschieden, welche Persona diese Fähigkeit später nutzt. Die Reihenfolge der Bereitstellung wird in diesem Schritt noch nicht definiert, diese ergibt sich nachfolgend aus dem Status Quo sowie der priorisierten Use Case Pipeline der Fachbereiche und der daraus abgeleiteten Roadmap.

Technologieauswahl

Die Technologieauswahl kann entweder einem Greenfield-Approach, einem Brownfield oder einer Kombination (“Enriched Brownfield”) folgen. Beim Greenfield-Approach werden dabei keinerlei aktuell bestehende Technologien beachtet, sondern eine Technologieauswahl basierend auf den aktuellen Best-Practices am Markt getroffen. Dabei sollte trotzdem darauf geachtet werden, dass nicht für jede einzelne Capability eine eigene Technologie ausgewählt wird, sondern maximal je Building Block. Im Gegensatz dazu, setzt der Brownfield Approach auf eine komplette Wiederverwendung bestehender Technologiekomponenten.

Der Enriched Brownfield Approach verwendet so viele Technologiekomponenten wie möglich wieder, tauscht aber wo nötig Technologien aus oder ergänzt den bestehenden IT-Stack mit weiteren Technologien.

Abbildung: Funktionale Architektur mit Azure Komponenten

Zielarchitektur

Die Zielarchitektur ist ein finales Bild, dass detailliert die Technologien incl. Versionsnummern, Locations, Netzwerken und Datenflüssen beschreibt. Diese Architektur wird dann neben dem Status-Quo als Grundlage für die Gap-Analyse, die Roadmap und die folgende Implementierung genommen. Das Zielbild sollte auch so spezifisch sein, dass dieses in der nächsten Phase mit dem Status-Quo verglichen werden und ein konkretes Backlog zur für ein Implementierungsprojekt abgeleitet werden kann.

Fazit

Die Definition einer Zielarchitektur, die nicht nur modernen Buzzwords folgt, sondern die Erreichung der Unternehmensziele unterstützt, kann nicht durch ein einzelnes Lösungsmuster erstellt werden, sondern muss spezifisch definiert werden. Dies kann nicht alleine aus der IT Abteilung heraus geleistet werden, da viele Einflüsse aus verschiedenen Domänen einen starken Einfluss auf die konkreten Anforderungen haben. Eine gute Kommunikation basierend auf Workshops ist nötig, um ein passendes Zielbild zu finden. Wir haben dieses Zielbild in vielen Projekten gemeinsam mit unseren Mandanten entworfen und unserem PwC Motto “From Strategy to Execution” bis zur erfolgreichen Umsetzung begleitet. Sprechen Sie uns an, gerne begleiten wir auch Sie in Ihrem Vorhaben.

Zu weiteren PwC Blogs