DEA Teil 5: Technologiearchitektur

November 2020, Markus Schacher (aktualisiert: Dezember 2020)

Es ist kaum verwunderlich, dass im Kontext einer digitalen Unternehmensarchitektur Technologie eine zentrale Rolle spielt. In diesem Artikel möchte ich aufzeigen, was Technologiearchitektur auf Unternehmensebene bedeutet und nach welchen Kriterien sie entwickelt und gepflegt werden sollte. Ich freue mich wiederum auf Feedback!

Technologie

Um darüber reden zu können, was eine Technologiearchitektur ist und soll, ist es hilfreich, erst einmal zu definieren, was unter dem Begriff Technologie überhaupt verstanden wird. Da nicht nur Finanz- oder Handelsunternehmen von der Digitalisierung betroffen sind, sondern ganz besondere auch Industrie- und Technologieunternehmen, möchte ich mich nicht bloss auf Informationstechnologie (IT) beschränken, sondern Technologie zuerst etwas allgemeiner definieren:

“Technologien sind vom Menschen geschaffene Hilfsmittel, die ihm helfen, in seinem Umfeld seine Ziele einfacher zu erreichen.”

Basierend auf dieser ganz allgemeinen Definition lassen sich nun zwei Hauptkategorien von Technologien unterscheiden:

• Technologien, welche Material be- und verarbeiten
  Dazu zählen beispielsweise Transportmittel, Anlagen, Maschinen und Geräte, welche zur Produktion von Gütern oder zur Erbringung von Dienstleistungen verwendet werden.

• Technologien, welche Informationen be- und verarbeiten
  Dazu zählen beispielsweise 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 wird diese Unterscheidung noch etwas weiter ausdetailliert:

• 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.

Das folgende Bild illustriert den etwas fliessenden Übergang zwischen IT und OT:

Quelle: ANSI/ISA-95 Standard

Das obige Bild illustriert die Abgrenzung zwischen IT und OT in fertigenden Unternehmen, die als Ganzes oft auch als Cyber-physische System (CPS) bezeichnet werden. Eine solche ganzheitliche Betrachtung ist heute insbesondere im Hinblick auf die Sicherstellung der Cyber Security essentiell (siehe dazu auch [1]).

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 Spezialthemas soll ihm eine eigene Folge in dieser Artikelserie gewidmet werden.

Ein Metamodell für Technologiezusammenhänge

Über welche Zusammenhänge sollte dich ein Unternehmensarchitekt nun bewusst sein, um die oben genannten Fragen beantworten zu können? Bereits im letzten Teil dieser Artikelserie habe ich Elemente wie Fähigkeiten und Ressourcen eingeführt. Als Ressourcen bezeichne allgemein Hilfsmittel, die zur Erbringung einer gewünschten Fähigkeit (Capability) erforderlich sind.

In der Technologiearchitektur geht es nun in erster Linie – wie der Name schon sagt – 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 andern Rechnern zur Verfügung stellen.

Diese Zusammenhänge sind durch das folgende Metamodell für eine Technologiearchitektur formalisiert:

Quelle: KnowGravity

Zusammengefasst ist das obige Metamodell in der Lage, uns Fragen zu beatworten wie…

• welche Software auf welchem Rechner ausgeführt wird
• welche Fähigkeiten dadurch realisiert werden
• und 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) [2] (siehe auch Tel „Geschäftsarchitektur“ dieser Artikelserie) 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 dieses 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 (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, Unternehmensgeschichte und oft von politischen Gegebenheiten ab.

Teil-Architekturen der Technologiearchitektur

Ich verwende den Begriff der Technologiearchitektur etwas unterschiedlich zu TOGAF [3]. 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:

• Die Applikationsarchitektur beschreibt die Applikationen, Schnittstellen und Informationsflüsse eines Unternehmens sowie ihre Beziehungen zu Geschäftsprozessen, Geschäftsregeln, Datensammlungen und Rechnern.
• Die 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.
• Die Software-Architektur beschreibt die Betriebssysteme, Plattformen, Programmbibliotheken und Kommunikationsmittel eines Unternehmens sowie ihre Beziehungen zu Rechnern, Applikationen, Datensammlungen.
• Die 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. Dies ist dann Gegenstand der nächsten Folge dieser Serie.

Ergänzende Informationen

Enterprise Architecture Consulting, Enterprise Architecture Tooling, EAM-Ausbildung,  Adaptive Requirements Engineering™, Tool-Migration,

Bisher in dieser Serie erschienen:

• DEA Teil 1: Unternehmensarchitektur im Kontext der digitalen Transformation
• DEA Teil 2: Architektur-Frameworks
• DEA Teil 3: Modelle in der Architektur
• DEA Teil 4: Geschäftsarchitektur

DEA Teil 6

Im nächsten Teil dieser Serie möchte ich aufzeigen, wie sich die Geschäftsarchitektur und eine Technologiearchitektur gegenseitig beeinflussen und Techniken aufzeigen, wie sich die beiden Architekturen optimal aufeinander abstimmen lassen, um damit ein optimales Business/Technology-Alignment zu erreichen.

Referenzen

• [1] IT/OT & ISA-95 https://www.channelpartner.de/a/so-unterscheiden-sich-it-und-ot,3335362
• [2] BMM https://www.omg.org/spec/BMM/About-BMM/
• [3] TOGAF https://www.opengroup.org/togaf