Was ist eine Technologie-Architektur?
Im Kontext einer digitalen Unternehmensarchitektur spielt Technologie eine zentrale Rolle. Markus Schacher zeigt auf, was Technologie-Architektur auf Unternehmensebene bedeutet und nach welchen Kriterien sie entwickelt und gepflegt wird.
Autor/in
Markus Schacher
Datum
15.07.2021
Lesezeit
12 Minuten
Dieser Beitrag stammt aus einer Blogserie zum Thema digitale Unternehmensarchitektur.
Bisher veröffentlicht wurden die Beiträge:
- Teil 1: IT Architektur im Kontext der digitalen Transformation
- Teil 2: 4 Frameworks für die Unternehmensarchitektur
- Teil 3: Die Vorteile einer Geschäftsarchitektur
In seinem vierten Gastbeitrag wendet sich Markus Schacher dem Thema Technologie in der Unternehmensarchitektur zu.
Um darüber zu sprechen, was eine Technologie-Architektur ist und soll, müssen wir zunächst definieren, was unter dem Begriff «Technologie» überhaupt verstehen. Dabei beschränke ich mich nicht auf Informationstechnologien (IT), sondern fasse den Begriff Technologie etwas allgemeiner:
Technologien sind vom Menschen geschaffene Hilfsmittel, die ihm helfen, in seinem Umfeld seine Ziele einfacher zu erreichen.
Basierend auf dieser allgemeinen Definition lassen sich nun zwei Hauptkategorien von Technologien unterscheiden:
- Technologien, die Material be- und verarbeiten
Zum Beispiel Transportmittel, Anlagen, Maschinen und Geräte, welche zur Produktion von Gütern oder zur Erbringung von Dienstleistungen verwendet werden. - Technologien, die Informationen be- und verarbeiten
Zum Beispiel Rechner, Kommunikations- und Netzwerk-Hardware sowie Software-Technologien, welche zur Erbringung kognitiver Leistungen verwendet werden.
Interessant ist, dass heute bei den meisten Ausprägungen dieser beiden Technologie-Kategorien sowohl Hardware als auch Software zum Einsatz kommen:
- Materialverarbeitende Technologien nutzen informationsverarbeitende Technologien, um eine Vielzahl von Funktionen und Abläufen zu automatisieren (Maschinensteuerungen).
- Informationsverarbeitende Technologien erfordern physische Hardware, um überhaupt ihren Zweck erfüllen zu können (Ausführungsplattformen).
Im Umfeld der Fertigungsindustrie differenziert sich diese Unterscheidung noch etwas weiter aus:
- Als Informationstechnologien (IT) werden virtuelle Technologien bezeichnet, welche Büro- und Verwaltungsaufgaben in einem Unternehmen unterstützen.
- Als Operationelle Technologien (OT) werden physische Technologien bezeichnet, welche Shopfloor- und Produktionsaufgaben in einem Unternehmen unterstützen.
Die folgende Grafik illustriert die Abgrenzung zwischen IT und OT in fertigenden Unternehmen, die als Ganzes oft auch als Cyber-physische Systeme (CPS) bezeichnet werden. Eine solche ganzheitliche Betrachtung ist heute insbesondere im Hinblick auf die Sicherstellung der Cyber Security essentiell.
Quelle: ANSI/ISA-95 Standard
Übersicht von Technologien für die digitale Transformation
|
- Verwaltungs-Software (ERP, CRM, MES, …)
- Echtzeit-Steuerungen (SPS, Eingebettete Systeme, …)
- AI (Machine Learning, Rule Engines, NLP, Bots, Constraint Solver, RPA, …)
- Moderne UI-Technologien (Augmented Reality (AR), Virtual Reality (VR), …)
- Kommunikation (Fiber, NFC, Bluetooth, WLAN, LTE/5G, OPC-UA, …)
- Edge Computing (Mobiles, Wearables, Embedded Devices, …)
- Datenhaltungssysteme (relationale und post-relationale Datenbanken, Speicher-Devices, …)
- Container und Virtualisierungsplattformen (Docker, Hypervisor, etc.)
- Cloud (Public, Private, Hybrid) und IoT-Plattformen
- DLT (Blockchain, Tangle, Smart Contracts, …)
- Analog-Digital Konversion (Sampling, Imaging, Scanning, …)
- Digital-Analog Konversion (Audio- und Videoanlagen, 2D/3D-Printing, …)
- Security Technologien (Encryption, IAM, digitale Signaturen, …)
Nutzen einer Technologiearchitektur
Die Technologiearchitektur beschreibt die technologischen Hilfsmittel, wie Maschinen oder IT-Systeme, aber auch Daten, die ein Unternehmen nutzt, um sein Geschäft auszuführen. Basierend auf der im dritten Teil eingeführten Unterscheidung zwischen deskriptiven (beschreibenden) und präskriptiven (vorschreibenden) Modellen lassen sich Modelle der Technologiearchitektur beispielsweise für die folgenden Fragestellungen nutzen:
Fragestellungen, die das Verständnis über das Unternehmen fördern und daher die Entscheidungsfindung unterstützen:
- Welche Maschinen und/oder Rechner stehen am Standort XY?
- Wo überall haben wir Kundendaten?
- Welche Applikationen greifen auf Kundendaten zu?
- Welche Technologien verwenden wir?
- Welche Daten werden in Applikation XY verarbeitet?
- Welche Schnittstellen hat Applikation XY und welche Daten fliessen über diese Schnittstellen wohin?
- Von welchen anderen Microservices ist Microservice XY abhängig?
- Wo und in welcher Sicherheitszone steht Rechner XY?
- Welche Rechner haben den Betriebssystem-Patch XY noch nicht installiert
Fragestellungen, die Verhaltensvorgaben für Personal und Partner machen:
- Welche Prinzipien gelten für selbst entwickelte Software?
- Welche Technologien sollen/dürfen eingesetzt werden?
- Welche heute eingesetzten Technologien sollen prioritär ersetzt werden?
- In welche Technologien soll prioritär und warum investiert werden?
- Welche Informationen bzw. Daten dürfen wo und wo nicht und zu welchem Zweck gespeichert werden?
Insbesondere mit der letzten Fragestellung öffnet sich eine ganz eigene Büchse der Pandora, nämlich diejenige der Informationssicherheit und des Datenschutzes. Aufgrund der Wichtigkeit dieses Themas, soll ihm eine eigene Folge in dieser Artikelserie gewidmet werden.
Ein Metamodell für Technologie-Zusammenhänge
Über welche Zusammenhänge sollte sich ein Unternehmensarchitekt nun bewusst sein, um die oben genannten Fragen beantworten zu können? In einem vorigen Artikel über die Vorteile einer Geschäftsarchitektur, habe ich Elemente wie Fähigkeiten und Ressourcen eingeführt. Als Ressourcen bezeichnet man allgemein Hilfsmittel, die zur Erbringung einer gewünschten Fähigkeit (Capability) erforderlich sind.
In der Technologie-Architektur geht es nun in erster Linie, um Technologie-Ressourcen. In vielen Fällen sind damit physische Ressourcen wie Geräte, Maschinen oder ganze Anlagen gemeint. Personelle Ressourcen sowie Verbrauchs-Ressourcen, wie Materialien oder Energie, werden hier nicht weiter betrachtet, da sie schwerpunktmässig Gegenstand des operativen Geschäfts sind.
Um aber erforderliche Fähigkeiten zu realisieren, benötigen diese physischen Ressourcen oft Know-how, wie sie nutzbringend zu verwenden sind. Dieses Know-how kann durch das spezialisierte Personal eines Unternehmens bereitgestellt werden. Im Zeitalter der Digitalisierung wird dieses Know-how aber natürlich zunehmend durch Software-Applikationen automatisiert. Damit Software aber auch ihre Fähigkeiten entfalten kann, muss sie auf einem Rechner, einer physischen Ressource ausgeführt werden.
Die Rechner eines Unternehmens befinden sich jeweils an einem spezifischen Standort und sind über ein oder mehrere Netzwerke (inklusive Cloud) untereinander verbunden, über die auf verschiedenen Rechnern ausgeführte Software-Komponenten via Schnittstellen (APIs) Informationen austauschen können. Schliesslich betreiben einige dieser Rechner Datenbanken in denen sie wichtige Unternehmensinformationen speichern und über das Netzwerk anderen Rechnern zur Verfügung stellen.
Diese Zusammenhänge sind durch das folgende Metamodell für eine Technologiearchitektur formalisiert:
Quelle: KnowGravity
Zusammengefasst beantwortet das Metamodell folgende Fragen:
- Welche Software auf welchem Rechner ausgeführt wird.
- Welche Fähigkeiten dadurch realisiert werden.
- Welche Informationen dazu benötigt und wie mit wem ausgetauscht werden.
Aus ökonomischer Sicht ist zu beachten, dass die verfügbaren Ressourcen eines Unternehmens bei der Einschätzung von Einflussfaktoren sowie der darauf aufbauenden Ausarbeitung von Strategien und Taktiken zu berücksichtigen sind. Dies wird im Business Motivation Model (BMM) neben dem Begriff «Resource» (einer Verbrauchs-Ressource) auch durch den Begriff eines «Fixed Assets» (eines Anlageguts) eines Unternehmens abgebildet.
Typen und Instanzen
Unter Umständen ist im Zusammenhang mit Ressourcen eine weitere Detaillierung des Metamodells erforderlich: Ein Rechner kann ja mehrere Software-Komponenten ausführen und umgekehrt kann eine Software-Komponente auf mehreren Rechnern ausgeführt werden.
Da stellt sich die Frage, was mit «Rechner» genau gemeint ist: Ein Typ eines Rechners (z.B. ein HP EliteBook 850) oder eine spezifische Instanz (z.B. mein HP EliteBook 850)? Dieselbe Frage lässt sich auch für die Software stellen: Ist mit «SAP» die SAP-Software als Typ im allgemeinen gemeint oder die SAP-Installation in unserem Unternehmen, welche z.B. auf der Test-Umgebung installiert ist, also eine spezifisch konfigurierte Instanz?
Sollen nicht nur Typen von Ressourcen unternehmensweit verwaltet werden, sondern auch spezifische Instanzen dieser Typen, so rutscht man in die Domäne einer Configuration Management Database (CMDB) nach ITIL und somit ins Grenzgebiet der Unternehmensarchitektur. Hier sind grundsätzlich drei Ausprägungen denkbar:
- In der Unternehmensarchitektur werden nur Typen von Ressourcen verwaltet, d.h. die Inventarisierung von Instanzen wird einer CMDB (und vermutlich auch anderen Leuten) überlassen.
- In der Unternehmensarchitektur werden sowohl Typen als auch Instanzen von Ressourcen verwaltet, d.h. ein Unternehmensarchitektur-Repository übernimmt auch die Aufgabe einer CMDB.
- Es wird zwischen «grossen» Enterprise-Level Hard- und Software (Cluster, Server, Enterprise-Software) und kleiner Client Hard- und Software (PC, Notebooks, Mobiles sowie lokal installierte Software) unterschieden: Für Enterprise-Level Hard- und Software werden sowohl Typen als auch Instanzen verwaltet und für Client Hard- und Software lediglich Typen (und die Instanzen ggf. in einer CMDB).
TOGAF macht die Unterscheidung zwischen Typen und Instanzen von Ressourcen im Gegensatz zu ITIL nicht. Welche der obigen Variante für ein Unternehmen die richtige ist, kann nicht allgemein bestimmt werden – dies hängt von der jeweiligen Situation, der Unternehmensgeschichte und oft von politischen Gegebenheiten ab.
Teil-Architekturen der Technologiearchitektur
Ich verwende den Begriff der Technologiearchitektur etwas unterschiedlich zu TOGAF. In TOGAF wird unter Technologiearchitektur lediglich die Hardware- und Software-Infrastruktur verstanden, die erforderlich ist, die fachliche IT eines Unternehmens zu betreiben. Dies greift meiner Meinung nach aber zu kurz: Mindestens Applikationen, Datenbanken und ggf. Maschinen sind meiner Meinung nach auch Technologien. Daher betrachte ich die folgenden spezifischeren Teil-Architekturen als Bestandteile der Technologiearchitektur:
Applikationsarchitektur: beschreibt die Applikationen, Schnittstellen und Informationsflüsse eines Unternehmens sowie ihre Beziehungen zu Geschäftsprozessen, Geschäftsregeln, Datensammlungen und Rechnern.
Datenarchitektur: Beschreibt die Datensammlungen, Entitäten und Informationsflüsse eines Unternehmens sowie ihre Beziehungen zu Applikationen, Rechnern, Geschäftsprozessen und Geschäftsregeln. Das Thema «Datenarchitektur» ist eine so wichtige Grundlage eines Unternehmens, dass diesem Thema eine eigene zukünftige Folge in dieser Artikelserie gewidmet wird.
Software-Architektur: Beschreibt die Betriebssysteme, Plattformen, Programmbibliotheken und Kommunikationsmittel eines Unternehmens sowie ihre Beziehungen zu Rechnern, Applikationen, Datensammlungen.
Hardware-Architektur: Beschreibt die Rechner, Cluster, Netzwerkkomponenten, aber auch die Zonen und Kommunikationswege zwischen Standorten eines Unternehmens sowie ihre Beziehungen zu Applikationen und Datensammlungen.
Der Begriff der Software-Architektur wird oft auch anders interpretiert: Als eine Beschreibung, wie ein konkretes Software-System (z.B. eine Applikation) aufgebaut ist – aus welchen Komponenten, Layern, Pattern, etc. das Software-System aufgebaut ist. Um Verwechslungen mit dem Begriff Software-Architektur zu vermeiden empfehle ich dafür den Begriff der Software-Anatomie zu verwenden. Die Software-Anatomie befindet sich allerdings normalerweise ausserhalb des Kompetenzbereichs eines Unternehmensarchitekten.
Fazit
Die oben beschriebenen Überlegungen spielen sich im Model Driven Enterprise Engineering Framework in den dritten und vierten Quadranten ab und können unter der Disziplin Systems Engineering zusammengefasst werden:
Quelle: KnowGravity
Eine zentrale Aufgabe eines Unternehmensarchitekten ist es, für die Realisierung der erforderlichen Geschäftsfähigkeiten eines Unternehmens geeignete Technologien zu wählen und diese in einer ökonomischen Art und Weise zu pflegen und weiterzuentwickeln.
Umgekehrt muss er aber auch technologische Entwicklungen beobachten und deren Nützlichkeit für das Unternehmen beurteilen, sodass das Unternehmen mit neuen technologischen Fähigkeiten auch gänzlich neue Geschäftsfelder erschliessen kann.
Dieses Thema wird Gegenstand des nächsten Beitrags in dieser Serie sein.
Weitere Teile der Blogserie:
Kommentar