Architekturen für eGovernment

Fünf Regeln für den SOA-Erfolg

Seite: 3/3

Firmen zum Thema

Strategische Qualitätssicherung

Diese Ebene der Architektur-QS adressiert das erste Mal wirklich die SOA, indem sie die Gesamtarchitektur (bestehend aus den vielen Einzelarchitekturen) einem umfassenden Check unterzieht. Es wird geprüft, ob die unterschiedlichen Architekturen aufeinander abbildbar sind und die so entstehende Kombination die übergreifende Geschäftsstrategie unterstützt. Dieser Schritt ist jedoch erst sinnvoll, wenn die beiden vorherigen Ebenen erfolgreich durchlaufen worden sind.

Auf diese strategische Ebene bezieht sich auch das Fanal der Burton Group: „SOA ist tot.“ Im Kern bezieht sich diese Aussage nicht auf die syntaktische oder semantische Architekturebene, denn diese müssen als Vorbedingung einer erfolgreichen SOA in jedem Fall existieren.

Bildergalerie

Vielmehr stellt die Aussage eine fehlende strategische Verankerung von Service-Orientiertheit in allen Architekturen heraus. Insofern weist sie darauf hin, dass Projekte oft versuchen, eine technische SOA-Architektur in einer Nicht-SOA-Organisation oder in einem Nicht-SOA-Umfeld zu etablieren. Dieses Risiko besteht gerade auch für eGovernment, bei dem es die Akteure mit einer äußerst vielschichtigen und dezentral ausgeprägten Service-Landschaft zu tun haben.

Dies spricht allerdings nicht gegen, sondern für Architekturen. Denn erst eine solche Architektur-Analyse unter strategischen Aspekten kann Risiken im realen Umfeld von Behörden aufdecken – seien es Mängel in der Ablauforganisation oder bei der Definition von zum Beispiel Antragsbewilligungen, dem elektronischen Bereitstellen amtlicher Dokumente oder nur der Terminvereinbarung bei der Meldebehörde über das Internet. Insofern stellen Architekturen ein wertvolles Hilfsmittel dar, um die bereits existierenden Prozesse und Systeme einer strategischen Analyse zu unterziehen und fortlaufend zu verbessern.

Die fünf Regeln für eine erfolgreiche SOA

Was bedeutet diese Analyse für eGovernment und deren SOA-Bestrebungen? Architekturen als Grundlage einer SOA können ein wichtiges Hilfsmittel zur Realisierung von eGovernment sein, wenn vor allem folgende fünf Regeln eingehalten werden:

  • Identifikation der geeigneten Architektur-Menge: Es gibt mehrere Architekturen für ein System, die bestimmte Sichten realisieren. Die fünf in SAGA formulierten Architekturen stellen einen guten Startpunkt dar, sind aber durchaus um weitere Architekturen zu erweitern.
  • Syntaktische QS jeder Architektur: Was für jedes andere Projektergebnis selbstverständlich ist, muss auch für Architekturen gelten: Vorgabe von Notations-Standards, Verarbeitungswerkzeugen und Architektur-Templates.
  • Semantische QS jeder Architektur: Eine Architektur hat nur dann einen Wert, wenn ihre Beschreibung auch konform zur Realität ist. Viele, vor allen Dingen technische Architekturen, können heute bereits werkzeuggestützt verifiziert werden.
  • Strategische QS aller Architekturen: Hier gilt es, die Synchronisierbarkeit der einzelnen Architekturen und ihr Zusammenspiel mit der Geschäftsstrategie zu überprüfen. Architekturen spielen gerade hier ihren größten Wert aus. Identifizierte Abweichungen sprechen nicht gegen Architekturen, sondern dafür, dass sie helfen, Schwachstellen zu erkennen. Methoden wie zum Beispiel die etablierte Architecture Tradeoff Analysis Method (ATAM) des Software Engineering Institute (SEI) unterstützen dieses Vorgehen.
  • Verantwortung für Architekturen: All diese Aufgaben müssen sowohl für Inhouse-Entwicklungen als auch für beauftragte Projekte sichergestellt werden. Es ist die Aufgabe des Qualitätsmanagements innerhalb eines Amtes/einer Behörde oder eines Ministeriums, Architekturen wie andere Artefakte auch als schützenswerte Objekte zu verstehen und zu pflegen.

(ID:2022877)