Fünf Regeln für den SOA-Erfolg

Anbieter zum Thema

cit GmbH

USU Software AG

mgm technology partners GmbH

Qualität von Architekturen

Eine solch methodische Auseinandersetzung mit Architekturen stellt eine mächtige Möglichkeit dar, Architekturen für eGovernment-Projekte zunächst zu abstrahieren und dann sinnvoll einzusetzen. Außerdem hilft sie, eine Vielzahl gescheiterter SOA-Projekte zu verstehen, die ohne entsprechende Architekturendefinition durchgeführt wurden.

Damit kommt der Qualitätssicherung (QS) von Architekturen eine wichtige Rolle zu. Geschieht dies nicht, bleibt der Wert einer Architektur mittel- und langfristig unklar beziehungsweise gering. In diesem Fall sind Architekturen in der Tat nicht hilfreich und SOA kann wirklich als tot bezeichnet werden.

Syntaktische Qualitätssicherung – Klarheit vor Schönheit: Die syntaktische Qualitätssicherung von Architekturen ist die einfachste Ebene und betrachtet die einzelne Architektur, unabhängig davon, welches System und welches Kriterium ihr zugrunde liegt. Hier prüfen die Qualitätssicherer vor allem die Verständlichkeit und Konsistenz der verwendeten Notation. Diese folgt bestenfalls einem etablierten Standard wie zum Beispiel der Unified Modeling Language (UML).

Darüber hinaus gilt es, die Wartbarkeit der Architekturdokumentation zu prüfen, um Änderungen an ihr ohne größeren Aufwand vornehmen lassen zu können und sie werkzeugbasierend weiter zu verwenden.

Schließlich ist gerade die Portierbarkeit der Architekturdokumentation ein wichtiger Faktor. Diesbezüglich stellt die QS sicher, dass die Architekturbeschreibung mit den im jeweiligen Kontext vorhandenen Werkzeugen bearbeitet und zwischen den einzelnen Tools bestmöglich ausgetauscht werden kann.

Selbst auf dieser sehr einfachen Ebene zeigt die Praxis, dass viele Projekte Kardinalfehler machen, indem sie zum Beispiel eigene, nicht standardisierte Notationen erarbeiten, Legenden gar nicht oder nur unvollständig mitgeben oder die Architektur so ablegen, dass sie kaum mehr geändert werden kann. Ein Beispiel zeigt Abbildung 1: Bei dieser Darstellung ist völlig unklar, welche Bedeutung die unterschiedlich eingefärbten Pfeile haben, was die Storages sind (vermutlich Datenbanken) und warum es so viele Synchronizer gibt. Darüber hinaus ist das Dokument eine MS-Paint-Grafik, in der Bearbeitungen kaum oder nur sehr zeitaufwendig möglich sind. Eine solche Architektur stellt tatsächlich keinen echten Wert für das eGovernment dar. Auch eine SOA scheitert auf Basis solcher Grundlagen.

Semantische Qualitätssicherung – Fakten anstelle von Fantasie: Diese Ebene der Architektur-QS adressiert das Zusammenspiel einer konkreten Architektur mit dem realen System. Die Qualitätssicherung überprüft hier, ob die Architekturbeschreibung korrekt ist, ob also die Architekturbeschreibung mit dem realen System übereinstimmt.

Konkret bedeutet diese Sicht für die QS: Existiert für jedes Objekt der Architektur ein entsprechendes Objekt im realen System und umgekehrt?

Passen beide nicht zusammen, ist die Architektur entweder veraltet oder – häufiger – entstammt dem Wunsch und der Fantasie des Erstellers. Wenn die Architektur diesen Test bestanden hat, ist bereits hier eine Evaluation mit der eGovernment-Strategie möglich. Es kann also geprüft werden, ob die Architektur die Strategie bestmöglich unterstützt beziehungsweise wo Schwachstellen existieren.

In der Praxis von IT-Projekten finden sich genügend Beispiele, die das Fehlen dieser QS-Aktivitäten demonstrieren: Häufig sind Architekturen mehr das Ergebnis von Wünschen, die damit lediglich darstellen, wie die konkrete Struktur einmal sein könnte. Auch die für eGovernment besonders wichtige Software-Architektur ist vor diesen Fehlern nicht gefeit: Häufig finden sich sauber modellierte Schichtenarchitekturen mit wohl definierten Schnittstellen auf allen Ebenen, die allerdings kaum einen Bezug zum tatsächlichen, häufig eher chaotischen System aufweisen. Denn tatsächlich kommuniziert dort fast jede Komponente mit allen anderen.

Ein typisches Beispiel für die Abweichung zwischen dem Ideal einer Software-Architektur und dem realen System zeigt Abbildung 2. Insbesondere für diesen Bereich der softwaretechnischen Architekturen existiert eine Vielzahl von Werkzeugen, die eine Überprüfung zwischen Spezifikation und Ist-Zustand semi-automatisch durchführen können.

Nächste Seite: Strategische Qualitätssicherung

(ID:2022877)