IT-Architektur und Integrationsmanagement

• Bereichsintegration:
  Integration innerhalb eines Sektors oder Prozesses
• Innerbetriebliche Integration:
  Integration innerhalb eines Unternehmens
• Zwischenbetriebliche Integrations:
  Integration über Unternehmensgrenzen hinweg

• Technische Ebene:
  • Wie sind die Systeme miteinander verbunden?
  • Welche Netzwerktechniken kommen zum Einsatz?
• Syntaktische Ebene:
  • Wie sind die Daten aufgebaut?
  • In welcher Reihenfolge werden die Daten übermittelt?
• Semantische Ebene:
  • Welche Bedeutung haben die Daten?
• Pragmatische Ebene:
  • Von wem gehen welche Nachrichten aus?

• Optimalen Grad der Integration finden
• Hilfe für Gestaltung und Steuerung
• Kosten und Nutzen auf ein Optimum bringen

• Integrationsintensität beschreibt den Integrationsumfang und die Integrationsart
• Integrationsflexibilität beschreibt den Umfang der Standardnutzung

Das Prinzip der losen Kopplung ist eine Gestaltungsempfehlung: Ein Softwaresystem sollte so entworfen werden, dass die Module möglichst lose gekoppelt sind.

Ein Modul ist eine Komponente eines Software-Systems, die eine bestimmte und klar abgegrenzte Aufgabe übernimmt und über klar definierte Input-/Output-Schnittstellen verfügt.

• Funktionalität
• Kompatibilität der Schnittstellen eines Moduls mit anderen Modulen
• Dokumentation der Schnittstellen
• Erweiterbarkeit  / Wartbarkeit
• Einhaltung von Vorgaben und Standards
• Umfang / Komplexität

Definition:

Kohäsion beschreibt die Stärkes des Zusammenhangs der Elemente innerhalb einem Modul.

Gestaltungsempfehlung:

Die Module sollen möglichst so entworfen werden, dass die Kohäsion innerhalb der Module möglichst hoch ist.

 Definition:

Kopplung beschreibt die Stärke der Verbindungen zwischen den Modulen (Grad der Abhängigkeit von Modulen).

Gestaltungsempfehlung:

Ein Softwaresystem sollte so entworfen werden, dass die Module möglichst lose gekoppelt sind (d.h. der Grad der Abhängigkeit möglichst gering ist).

Je höher die Kohäsion einzelner Module, desto geringer ist die Kopplung zwischen den Modulen.

• Datenkopplung
• Datenstrukturkopplung
• Kontrollkoppkung

• Datenkopplung ist die einfachste Form der Kopplung zwischen zwei Modulen, da die Übertragungsparameter einfache Datenelemente darstellen
• Datenkopplung ist harmlos solange ...
  • keine Daten benötigt werden, die im empfangenden Modul nicht benötigt werden
  • die Anzahl der Übertragunsparameter nicht zu hoch ist
• Wenn die Anzahl der Übertragunsparameter gering ist, kann das aufgerufene Modul leicht von anderen (aufrufenden) Modulen verwendet werden

• Datenstrukturkopplung reduziert die Anzahl der Übergabeparameter
• Wenn die übergebene Datenstruktur ...
  • nur  Elemente enthält, die das empfangene Modul tatsächlich benötigt, ist die Datenstrukturkopplung ungefährlich
  • Elemente enthält, die das empfangende Modul nicht benötigt, wird die Verständlichkeit des Moduls reduziert

Charakterisierung:
Übergabeparameter funktionieren wie Steuerelemente und beeinflussen das Verhalten des empfangenden Moduls.

Nachteile:

• Eindeutigkeit der Übergabeparameter nicht gewährleistet
• Schwer verständlich, wartbar und testbar
• Zusätzliche Dokumentation nötig

• Ermöglicht es, ein Modul ohne detaillierte Kenntnis anderer Module zu verstehen
• Reduziert die Wahrscheinlichkeit, Fehler zu begehen
• Reduziert die Gefahr, dass Fehler in einem Modul fehlerhafte Symtome in einem anderen Modul erzeugen
• Erleichtert das Prüfen von Modulen und die Fehlerfindung
• Ermöglicht lokale Änderungen
• Erleichtert die Wiederverwendung von Modulen

Unter Informationsinfrastruktur versteht man die Gesamtheit aller Methoden und Hilfsmittel, die eingesetzt werden, um Informationen bereit zu stellen.

Daraus folgt, dass jedes System eine Architektur hat, die eine Abstraktion des abgebildeten Systems darstellt. Aber: Nicht jede Architektur muss dokumentiert sein!

Folglich definiert Architektur die Komponenten, welche das System auszeichnen und deren Beziehungen und Verbindung untereinander.

Unterschiedliche Stakeholder haben ein unterschiedliche Sichtweisen auf die Architektur (z.B. Geschäftsführung, Projektmanagement, Administration etc.) Daher gibt es nicht DIE Architekturrepräsentation, sondern viele verschiedene, die die unterschiedlichen Stakeholder adressieren.

Architektur: Die Architektur baut auf die wesentlichen und spezifischen Bedürfnisse der Stakeholder auf und entwickelt Lösungen, die diese Bedürfnisse befriedigen. Folglich beinhaltet Architektur die eigentliche Lösung.

Design: Beinhaltet die konkrete Konstruktion einer Lösung und dokumentiert Entscheidungen. Die Auswahl der nötigen Komponenten kann variieren, muss jedoch immer auf die Bedürfnisse des bzw. auf die Vorgaben der Architektur abgestimmt sein.
=> Realisation der Architektur

Architekturen werden im Wesentlichen für folgende Zwecke eingesetzt:

1. Deskriptiv: Architektur beschreibt bzw. modelliert ein bestehendes System.
2. Präskriptiv: Die Architektur definiert, wie ein zukünftiges System aufgebaut sein soll.

Eine IT-Architektur ist eine spezielle Form der Architektur, welche die IT bzw. das Umfeld der IT in einem Unternehmen beschreibt. Dabei stellt IT-Architektur ein Set aus Modellen, Richtlinien, Methoden und Standards zur Verfügung, um spezifische Architekturen zu entwickeln.

• Beschreibungsfunktion (Beschreibung des "Status Quo")
• Kommunikationsfunktion
• Bewertungsfunktion
• Lern- und Wissenstransferfunktion
• Managementfunktion (Planung, Steuerung, Kontrolle)
• Blaupause für Wartung und Verbesserung der IT-Landschaft eines Unternehmens

• Viele verschiedene Anwendungssysteme in einer Organisation
• Fehlende Transparenz
• Mangelnde Ausrichtung der Informationssysteme auf die Geschäftsmodelle und -prozesse
• Hohe Kosten für die Integration von "Insellösungen"
• Hohe Kosten durch Redundanz und Doppelarbeiten
• Komplexität der IS-Landschaft (Reduktion der Qualität, Erhöhung der Kosten)

• Viele verschiedene Anwendungssysteme in einer Organisation
• Fehlende Transparenz
• Mangelnde Ausrichtung der Informationssysteme auf die Geschäftsmodelle und -prozesse
• Hohe Kosten für die Integration von "Insellösungen"
• Hohe Kosten durch Redundanz und Doppelarbeiten
• Komplexität der IS-Landschaft (Reduktion der Qualität, Erhöhung der Kosten)

Die Unternehmensarchitektur ist ein Modell aus betriebswirtschaftlicher Sicht, das strategische Ziele sowie Verfahren und Ressourcen zur Realisierung dieser Ziele beschreibt.

Die Unternehmensarchitektur bildet die wichtigsten Artefakte eines Unternehmens und deren Beziehungen in Form von Modellen ab:

• Ist-Zustand (zum Zweck der Dokumentation und Analyse)
• Soll-Zustand (zum Zweck der Planung)

• Komponenten, Elemente, Artefakte
  (Betrachtungsgegenstände, z.B. betriebliche Aufgaben, Datenbestände, IS)
• Ebenen, Layers, Teilarchitekturen
  (Zusammenfassung inhaltlich zusammenhängender Betrachtungsgegenstände)
• Sichten und Perspektiven
  (Fokus bestimmter Interessesngruppen)
• Prinzipien
  (Grundsätze für Entwurf, Beschreibung und Bewertung von Unternehmensarchitekturen)

(siehe Abbildung).

• Dokumentation des Ist-Zustands des Unternehmens (implizites Wissen über die Struktur des Unternehmens explizieren)
• Analyse des Ist-Zustands (z.B. im Hinblick auf Redundanzen)
• Entwurf des Soll-Zustands
• Bewertung einzelner Entwicklungsvorhaben im Hinblick auf die Integrationsfähigkeit
• Qualitätsmangement
• IT-Sicherheitsmanagement
• IT-Compliance (z.B. um einen Überblick über Datenbestände mit personenbezogenen Daten zu bekommen)
• IT-Controlling
• IT-Servicemanagement (Configuration Management Database)

(siehe Abbildung)

• IT-Planung ist ein Teil der Unternehmensarchitektur
• Prozess der Beschreibung und Implementierung nennt sich "Enterprise Architecting".

• Eindeutigkeit, Verwechslungsfreiheit
• Relevante Architekturelemente, Ebenen und Sichten müssen abgebildet werden können
• Zusammenfassung von Elementen muss möglich sein
• Beziehungen zwischen Elementen muss dargestellt werden können
• Zeitliche Veränderung muss dokumentiert werden können (Versionierung, Vergleichbarkeit)
• Werkzeuguntersützung und Schnittstellen zu anderen Hilfsmitteln