Titel, 1. Zeile 32 pt Titel, 2. Zeile 32 ptUntertitel 20 pt

ELANElectronic Governmentand Applications

Studie zum Open Source Einsatz im Land Berlin

Kriterienkatalog zur dezentralen Softwarebeschaffung

FRAUNHOFER VERLAG

 

Kontaktadresse:  Fraunhofer‐Institut für Offene Kommunikationssysteme FOKUS Kaiserin‐Augusta‐Allee 31  10589 Berlin  Telefon:   +49‐30‐3463‐7115 Telefax :  +49‐30‐3463‐8000  E‐Mail: elankontakt@fokus.fraunhofer.de URL:  www.fokus.fraunhofer.de  Bibliografische Information der Deutschen Nationalbibliothek:  Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d‐nb.de abrufbar.  ISBN: 978‐3‐8396‐0136‐5  Druck und Weiterverarbeitung:  IRB Mediendienstleistungen Fraunhofer‐Informationszentrum Raum und Bau IRB, Stuttgart  Für den Druck des Buches wurde chlor‐ und säurefreies Papier verwendet.  © by Fraunhofer Verlag, 2010 Fraunhofer‐Informationszentrum Raum und Bau IRB Postfach 800469, 70504 Stuttgart Nobelstraße 12, 70569 Stuttgart Telefon   0711 970‐2500 Telefax  0711 970‐2508 E‐Mail  verlag@fraunhofer.de URL  http://verlag.fraunhofer.de   Alle Rechte vorbehalten  Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Verwertung, die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Speicherung in elektronischen Systemen. Die Wiedergabe von Warenbezeichnungen und Handelsnamen in diesem Buch berechtigt nicht zu der Annahme, dass solche Bezeichnungen im Sinne der Warenzeichen‐ und Markenschutz‐Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften. Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z.B. DIN, VDI) Bezug genom‐men oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität übernehmen.    

 

 

Aus Gründen der besseren  Lesbarkeit wird darauf verzichtet,  jeweils die weibliche und die männliche 

Bezeichnung  zu  verwenden.  Soweit neutrale  oder männliche Bezeichnungen  verwendet werden,  sind 

darunter jeweils weibliche und männliche Personen zu verstehen. 

 

Inhalt 

Zusammenfassung .................................................................................................................... 4 

Grundlagen der Studie .............................................................................................................. 5 

Ausgangssituation und Zielstellung ..................................................................................... 5 

Herangehensweise und Struktur ......................................................................................... 7 

Open‐Source vs. proprietäre Software .............................................................................. 10 

Terminologie ...................................................................................................................... 13 

IT‐Systeme: ein Kurzüberblick ............................................................................................ 14 

Auswahl von IT‐Systemen ....................................................................................................... 15 

Vorgehen zur Auswahl / Auswahlprozess .......................................................................... 15 

Herleitung der Auswahlkriterien ........................................................................................ 16 

Fazit und Handlungsempfehlungen......................................................................................... 34 

Literaturverzeichnis ................................................................................................................ 36 

Anhang ................................................................................................................................... 40 

Terminologie ...................................................................................................................... 40 

Kurzüberblick IT‐Systeme ................................................................................................... 44 

 

 4  Zusammenfassung 

Zusammenfassung 

Die vorliegende Studie von Fraunhofer FOKUS entwickelt aus den Leitgedanken zur Berliner Open Source 

Strategie einen Kriterienkatalog zur Auswahl und Beschaffung von IT‐Systemen. Sie stellt damit in Kom‐

bination mit dem dazugehörigen Kriterienkatalog ein Hilfsmittel zur Vereinheitlichung des Softwareaus‐

wahlprozesses  in den dezentralen Standorten der Berliner Verwaltung zur Verfügung. Die Entscheidun‐

gen bei der Auswahl bestimmter IT‐Lösungen sollen damit strukturierter und nachvollziehbarer gemacht 

werden. Unter Berücksichtigung der strategischen IT‐Ziele der Berliner Verwaltung sind  im Rahmen des 

Kataloges klare Richtlinien entstanden, die helfen  sollen, die  IT‐Landschaft der Berliner Verwaltung  zu 

harmonisieren, aber auch gleichermaßen den Entscheidungsspielraum der dezentralen Bereiche  (Bezir‐

ke, Ressorts, Ämter) bei der  Softwarebeschaffung  zu  erhalten. Gleichzeitig  gibt diese  Studie Auskunft 

darüber, welche Methoden und Standards hinzugezogen werden sollten, um zu den im Kriterienkatalog 

genannte Punkten ausreichend Stellung nehmen zu können. 

Der Kriterienkatalog zur Auswahl und Beschaffung von  IT‐Systemen  ist ein wesentlicher Bestandteil   ei‐

ner Gesamtberliner IT‐Strategie. 

  5Grundlagen der Studie 

Grundlagen der Studie 

Ausgangssituation und Zielstellung 

Die gesamten  IT‐Ausgaben der Berliner Verwaltung werden sich  im Jahr 2010 schätzungsweise auf 170

Millionen Euro belaufen (ca. 140 Mio. Euro  in 2009). Eine große Herausforderung für den Aufbau einer 

nachhaltigen,  integrierten  IT‐Landschaft  ist dabei die dezentrale Entscheidungshoheit, die auf zwölf Be‐

zirksverwaltungen, acht Senatsressorts und ca. 70 Behörden verteilt ist. 

Seit 30 Jahren, mit dem Beginn der PC‐Revolution, entstehen auf Ebene der Bezirke und Ressorts eine 

Vielzahl von heterogenen Insellösungen, die den heutigen Anforderungen an integrierte IT‐Landschaften 

nicht mehr entsprechen. Auf dieser technischen Basis lassen sich behördenübergreifende, elektronische 

Prozesse und Dienstleistungen nur schwer realisieren und somit auch Qualitäts‐ und Effizienzsteigerun‐

gen  im behördlichen Handeln nur mit hohem Aufwand erreichen. Zentrale Steuerungskonzepte mit der 

Zielstellung eine einheitliche  IT zu schaffen, stoßen bis heute auf Schwierigkeiten  in den einzelnen, de‐

zentralen Bereichen, da Vorinvestitionen und sonstige Bereichsinteressen geschont werden sollen. Die 

Verwaltungsreform zu Beginn der neunziger Jahre stärkte explizit die Budgethoheit der dezentralen Be‐

zirke. Hiermit wurden aber auch die Voraussetzungen für eine auf Standardisierung und Zentralisierung 

ausgerichtete IT‐Strategie genommen.  

Um  heute  eine  langfristige,  gesamtberliner  IT‐Planung  zu  entwickeln,  sollten  daher  strikte  Vorgaben 

vermieden werden, sondern eher Richtlinien zum Einsatz kommen, die zwar den Ressorts und Bezirken 

ihren Entscheidungsfreiheit  lassen, aber  trotzdem eine  langfristige Harmonisierung und Kompatibilität 

der  IT ermöglichen. Als Basis dafür muss die Stärkung des Bewusstseins dienen, dass das Fehlen einer 

expliziten IT‐Strategie für gesamt Berlin zu folgenden Problemen führen kann:  

• Ausufernde Kosten bei Beschaffung und Betrieb 

• Hohe Abhängigkeit von Herstellern oder bestimmten Technologien 

• Mangelnde Flexibilität 

• Ressourcenstau bei der Anwendungsentwicklung 

• Unzufriedenheit bei Mitarbeitern und Kunden (negatives Image der IT) 

• Hoher Abstimmungsbedarf  zwischen den Behörden bei  IT‐Neuanschaffungen oder Entwicklun‐

gen, da klaren Vorgaben zur Orientierung fehlen. 

 6  Grundlagen der Studie 

Grundgedanke der  IT‐Strategie  sollte es  sein,  allen Verantwortlichen und Akteuren Orientierung beim 

Aufbau oder der Umgestaltung von  IT‐Infrastrukturen zu bieten, um die genannten Risiken zu minimie‐

ren. Ein wichtiger Bestandteil ist dabei eine vereinheitlichte Beschaffung auf Basis strategischer Rahmen‐

vorgaben und daraus entwickelter Kriterienkataloge zur Unterstützung des Softwareauswahlprozesses in 

dezentralen Standorten. (Inneres, 2009) 

     

  7Grundlagen der Studie 

Herangehensweise und Struktur 

Bestandteil einer nachhaltigen  IT‐Strategie  ist die Vereinheitlichung des Softwareauswahlprozesses, um 

der  Heterogenität  in  der  IT‐Landschaft  entgegenzuwirken.  Um  den  Prozess  der  Softwareauswahl  zu 

strukturieren und nachvollziehbar zu machen, hat Fraunhofer FOKUS einen Kriterienkatalog entwickelt, 

der sich stark an den strategischen IT‐Zielen der Berliner Verwaltung orientiert. 

Der Katalog dient auf der einen Seite der Orientierung der Verantwortlichen im Auswahlprozess auf der 

anderen Seite der Bewertung des Auswahlverfahrens.  Jedem strategischen Ziel sind gängige Standards 

und Methoden zugeordnet, die  für eine aussagekräftige Bewertung geprüft bzw. durchgeführt werden 

sollten. Die Matrix  in  Form einer Kalkulationstabelle gibt die Möglichkeit, die Ergebnisse  zu bewerten 

und zu gewichten. Desweiteren sollte von den Nutzern eine Begründung für eventuell nicht vorgenom‐

mene Prüfungen gegeben werden. Die Basis für die erfolgreiche Beantwortung der meisten Fragen  lie‐

fert die sorgfältige Bearbeitung des ersten Teils der Matrix, die Systemanalyse. 

Open‐Source‐Software muss den gleichen  strategischen Zielen genügen, wie proprietäre Softwarepro‐

dukte. Die strategischen Ziele spiegeln  jedoch bewusst auch Kriterien wieder, bei denen Open‐Source‐

Software  konzeptionelle  Vorteile  besitzt  (Bsp.: Nachnutzung). Die  folgenden  Ziele  stammen  aus  dem 

Dokument „Leitgedanken zur IT‐Strategie Berlin“ und dienen als Basis für den Softwareauswahlprozess: 

Wirtschaftlichkeit 

Anschaffung und Betrieb 

IT‐Systeme sollten eine Dienstleistung mit möglichst geringem  finanziellen und 

personellen Aufwand erbringen. Es sollten auf der Kostenseite dabei umfassen‐

de Ansätze, wie Live Cycle Costs, Total Cost of Ownership, etc. verfolgt werden. 

Kostenreduzierung 

Die Kosten der Leistungserbringung sollen durch den Einsatz von IT gesenkt wer‐

den. 

Nachnutzung 

Die Möglichkeit  der  Veränderung  und  Erweiterung  der  Software  sowie  deren 

Weitergabe sollten gewährleistet sein, ohne dass dabei zusätzliche Lizenzkosten 

entstehen.  

 8  Grundlagen der Studie 

Kundenorientierung 

Die Qualität  der  Verwaltungsleistungen  aus  Sicht  von  Bürgern  und  Unternehmen  soll 

durch den Einsatz von IT gesteigert werden. Dies betrifft sowohl die Kommunikation zwi‐

schen Verwaltung, Bürgern und Wirtschaft, die durch IT Nutzung verbessert werden soll, 

als auch die Qualität und Effizienz der Leistungserbringung. Eine effiziente Verwaltung, 

deren schlanke Prozesse durch leistungsfähige IT unterstützt werden, stellt aus der Sicht 

von Unternehmen (als Kunden der Verwaltung) einen wichtigen Vorteil im Standortwett‐

bewerb dar. 

Beschäftigungsorientierung 

Die Verbesserung der Arbeitsbedingungen von Mitarbeitern soll durch den Einsatz mo‐

derner, ergonomischer Softwareprodukte erfolgen und damit die Verwaltungsmitarbei‐

ter optimal bei der Erfüllung ihrer Aufgaben unterstützen. 

Herstellerunabhängigkeit 

Eine  feste Bindung an Hersteller oder proprietäre Standards soll vermieden werden, da 

diese durch potentielle Migrationskosten die Gefahr eines „Vendor‐Lock‐Ins1“ bergen. 

Vernetzung 

Die Kooperation verschiedener Behörden soll, auch über die  fachliche Zusammenarbeit 

in Verwaltungsprozessen hinaus, gefördert werden. Wichtig  ist hierbei die Orientierung 

auf einfache, schnell umzusetzende Maßnahmen, beispielsweise bei der Schaffung eines 

gemeinsamen  Telefonverzeichnisses  oder  von  Rollout‐Mechanismen  zur  vereinfachten 

Verteilung von Software. 

   

                                                            1 Lock‐In‐Effekte nennt man Kosten, die eine Änderung der aktuellen Situation unwirtschaftlich machen, beispiels‐weise Migrationskosten auf neue Systeme. 

  9Grundlagen der Studie 

Sicherheit 

Die Sicherheit von  IT‐Systemen  spielt  im öffentlichen Bereich eine besondere Rolle, da 

meist mit sensiblen, personenbezogenen Daten umgegangen wird. Die Daten müssen vor 

dem  unbefugtem  Erzeugen,  Ändern  und  Einsehen  geschützt werden.  Die  eingesetzte 

Sicherheitstechnik muss dabei  stets dem  jeweiligen  Stand der Technik genügen, damit 

potentiellen Angreifern der Zugang unmöglich gemacht wird, oder zumindest die Über‐

windung der Sicherheitsmaßnahmen nur mit einem möglichst hohen Aufwand erfolgen 

kann.  

Zukunftsfähigkeit 

Die Nutzung einer Technologie soll längerfristig ausgerichtet sein, wobei auch Hersteller 

und Dienstleistung im Bereich Support und Wartung längerfristig verfügbar sein müssen. 

Zusätzlich sollten IT‐Systeme auch bei zukünftigen Änderungen der übrigen IT‐Landschaft 

oder der zu unterstützenden Prozessabläufe weiter eingesetzt werden können. Um diese 

Forderungen erfüllen zu können, ist darauf zu achten, dass IT‐Systeme Kommunikations‐

schnittstellen und Datenformate anbieten, die unter Berücksichtigung von frei verfügba‐

ren (offenen) Standards realisiert werden. 

Regionale Förderung 

Die nicht unerheblichen Kosten, die für die Beschaffung und den Betrieb von IT‐Systemen 

in der Berliner Verwaltung aufgewendet werden, sollen auch der Förderung der regiona‐

len Wirtschaft dienen und damit auch zur Schaffung bzw. zum Erhalt von Arbeitsplätzen 

in  der  Hauptstadtregion  beitragen.  Da  diese  regionalen  Arbeitnehmer  sozialabgaben‐ 

und steuerpflichtig sind, tragen sie auch zur Finanzierung der Bezirke, der Stadt und des 

Landes Berlin bei. 

(Inneres, 2009) 

 10  Grundlagen der Studie 

Open­Source vs. proprietäre Software 

Open‐Source‐Software  (OSS) hat sich zu einer ernstzunehmenden Alternative zur heute noch dominie‐

renden proprietären Software entwickelt. Das Geschäftsmodell von kommerziell orientierten Software‐

herstellern basiert auf der Geheimhaltung der Programmquellen und unterliegt Lizenzbedingungen, die 

das Kopieren, Modifizieren und Weiterverbreiten untersagen. Auch die Nutzung  ist nur nach dem kos‐

tenpflichtigen Erwerb einer Lizenz möglich. Der Hersteller bleibt alleiniger Eigentümer und hat somit die 

vollständige Kontrolle über das Produkt. 

OSS unterliegt zwar ebenfalls einer Lizenz, die aber  im Gegensatz zu proprietärer Software die Freiheit 

der uneingeschränkten Nutzung, des Studierens der Programmquellen, des Modifizierens nach eigenem 

Ermessen, des Kopierens und der Weitergabe an Dritte sowie die Veröffentlichung von abgeleiteten Ar‐

beiten garantiert. 

Die OSS‐Bewegung betrachtet die eigentliche Software als Infrastruktur der Informationsgesellschaft und 

möchte sie zu einem öffentlichen Gut (ähnlich wie Straßen) machen. Wirtschaftliche Gewinne lassen sich 

dann  aus Dienstleistungen  (wie  z.B.  Konfektionierung, Anpassung,  Schulung, Wartung,  etc.)  beim An‐

wender erzielen. 

OSS weist eine Reihe von Vorteilen gegenüber proprietärer Software auf, die aber aus der Sicht einer 

öffentlichen Verwaltung unterschiedlich gewichtet sind. Eine Berliner Verwaltung geht  im Allgemeinen 

davon aus, dass Software beschafft, konfektioniert und gepflegt wird, aber keine eigene Softwareent‐

wicklung stattfindet oder beauftragt wird. Die Reihenfolge der im Folgenden aufgeführten Vorteile spie‐

gelt diese Gewichtung wieder: 

• Durch die freie Verfügbarkeit der Programmquellen wird die Berliner Verwaltung unabhängiger 

von Herstellern. Bei proprietären Softwareprodukten ist ausschließlich der Hersteller in der Lage 

Fehler zu beheben, individuelle Anpassungen durchzuführen und Weiterentwicklung zu betrei‐

ben.  Dagegen kann dies bei OSS durch mehrere Unternehmen durchgeführt und der Verwaltung 

als Dienstleistung angeboten werden. Ein Beispiel dafür ist das Angebot von unterschiedlichen 

Linux‐Betriebssystem‐Distributionen durch verschiedene Unternehmen. Der auslaufende Sup‐

port von proprietären Softwareprodukten ermöglicht es dem Hersteller den Zyklus des Updates 

auf eine neuere Version zu diktieren, wodurch auch zyklisch Lizenzkosten anfallen.  Bei Insolvenz 

eines Herstellers kann auch das proprietäre Softwareprodukt nicht mehr gepflegt oder gar wei‐

terentwickelt werden, was eine Verwaltung zum Umstieg auf ein alternatives Produkt zwingt. Bei 

OSS existieren meist mehrere Unternehmen, die den Support übernehmen können, wie auch 

  11Grundlagen der Studie 

wegfallende OSS‐Entwickler in der Regel durch Andere ersetzt werden und damit eine längerfris‐

tige Pflege und Weiterentwicklung gewährleistet ist. 

• Bei OSS fallen keine Lizenzkosten an.  Proprietäre Softwareprodukte dürfen nur nach dem Er‐

werb einer kostenpflichtigen Lizenz eingesetzt werden. Das damit verbundene Nutzungsrecht ist 

auf ein oder mehrere Systeme, Prozessoren oder Benutzer beschränkt. In der Regel fallen weite‐

re Lizenzkosten an, wenn neuere Versionen des Softwareprodukts auf den Markt kommen und 

genutzt werden.  Open Source Lizenzen verbieten dagegen die Erhebung von Lizenzgebühren. 

Lediglich für das Erstellen von Kopien bzw. das Drucken von Benutzerhandbüchern dürfen Ge‐

bühren erhoben werden. 

• Der offene Entwicklungsprozess bei OSS ermöglicht schnell eine gesicherte Stabilität und meist 

bessere Qualität der Software. Die Programmquellen sind in der Regel schon zu Beginn der Ent‐

wicklung frei verfügbar, so dass bereits in einem frühen Stadium Fehler im Design und Programm 

durch andere interessierte Entwickler oder potentielle Anwender aufgezeigt werden können. 

Das sog. „Mehr‐Augen‐Prinzip“ ist damit im Vorteil gegenüber  einer  abgeschirmten Entwickler‐

abteilung eines Unternehmens, das seine Produkte meist erst zum Verkaufsstart der Öffentlich‐

keit vorstellt und seine Programmquellen verbirgt. Die Beseitigung von Schwachstellen und 

Fehlern unterliegt bei Herstellern von proprietärer Software fest vorgegebenen Patch/Release‐

Zyklen, was zu zeitlichen Verzögerungen führt. Dagegen werden Schwachstellen oder Fehler 

durch die OSS‐Entwickler zeitnah beseitigt und Patches/Updates zum Download bereitgestellt. 

Auch wenn die Berliner Verwaltung keine Eigenentwicklung von Software betreibt, so hat doch 

die Stabilität und Qualität einer eingesetzten Software eine maßgebliche Bedeutung. 

• OSS bietet die Möglichkeit die Programmquellen zu überprüfen, ob sie Hintertüren bzw. Sicher‐

heitsmängel aufweisen. Neben der Einsicht in die Programmquellen lässt sich aus OSS auch das 

jeweilige ablauffähige Binärprogramm erstellen, um damit sicherzustellen, dass nicht während 

dieses Prozesses noch weitere und damit verborgene Komponenten eingeschleust werden. Bei 

proprietären Softwareprodukten ist die Möglichkeit nicht gegeben, da der Hersteller die Pro‐

grammquellen verbirgt. Aus Sicht der Berliner Verwaltung ist eine umfassende Sicherheitsüber‐

prüfung und die nachweisliche Generierung aus OSS‐Programmquellen schon aus Kostengrün‐

den nicht denkbar, sollte aber in besonderen sicherheitsrelevanten Bereichen nicht ausgeschlos‐

sen sein. 

   

 12  Grundlagen der Studie 

• OSS ermöglicht die Anpassung an individuelle Bedürfnisse des Anwenders. Da die Programm‐

quellen von OSS frei verfügbar sind, kann die Berliner Verwaltung individuelle Anpassungen 

selbst durchführen oder im Auftrag durch OSS‐Unternehmen vornehmen lassen. Die Kosten für 

die Anpassung einer existierenden Open Source Lösung sollten in der Regel geringer sein, als die 

vollständige Neuentwicklung, die z.B. bei der Einführung einer  weiteren Fachanwendung not‐

wendig wäre. 

   

  13Grundlagen der Studie 

Terminologie 

Wie  im Bereich der kontinuierlichen Modernisierung anderer technischer  Infrastrukturen, geht es auch 

im Bereich der für die Verwaltung notwendigen IT‐Infrastrukturen um eine gründliche, vorausschauende 

und umfassende Planung von Maßnahmen. Diese betreffen in der Regel die Konzeption, den Aufbau, die 

Tests  sowie  die  Sicherstellung  eines  fehlerfreien  Betriebes  einer  Vielzahl  technischer  Komponenten. 

Funktionalen  Zuordnungsprinzipien  (Architekturen) und Normen  für die Nutzung und Verbindung  von 

Komponenten  (Standards)  kommen dabei  in allen  technischen  Infrastrukturen eine besondere Bedeu‐

tung zu.  Im Handlungsbereich prozessorientierter  IT‐Infrastrukturen  (E‐Business, E‐Government) haben 

sich in den letzten Jahren sowohl im nationalen wie im internationalen Maßstab verschiedene Architek‐

turmodelle, Betrachtungsweisen und Konzepte durchgesetzt. 

Allen voran steht die sogenannte Service Orientierte Architektur (SOA), ein flexibles Architektur‐Konzept, 

bei dem verteilte  IT‐Komponenten als Dienste gekapselt und über prozessbasierte Plattformen orches‐

triert werden. Einmal gekapselte und über gut dokumentierte Schnittstellen zugänglich gemachte Diens‐

te können  je nach auftretenden Anforderungen gebündelt und  in verschiedenen Kontexten wiederver‐

wendet werden. Als Kommunikationsstandard hat sich die Webservice‐Technologie durchgesetzt, da sie 

eine  lose Kopplung der Dienste erlaubt und dank XML‐Technologie einfach zu  implementieren und auf 

vielen Plattformen verfügbar ist (technische Interoperabilität). 

Weitere wichtige technologische Standards zur Erreichung von Interoperabilität und Wiederverwendbar‐

keit werden in „Standards und Architekturen für E‐Government‐Anwendungen“ (SAGA) von der „Koordi‐

nierungs‐ und Beratungsstelle der Bundesregierung  für  Informationstechnik  in der Bundesverwaltung“ 

(KBSt) aufgelistet und bieten Orientierung beim Aufbau heterogener, verteilter  IT‐Landschaften. Zur Si‐

cherung von semantischer Interoperabilität bieten sich die XML‐Schemas für die Öffentliche Verwaltung 

(XÖV) als Basis für den elektronischen Austausch fachspezifischer Daten an. 

Der Aufbau komplexer verteilter Systeme verlangt nach einer differenzierten Betrachtungsweise, da eine 

Vielzahl  von Akteuren unterschiedliche Anforderungen definieren und umzusetzen haben. Hier bietet 

sich RM ODP mit seinen fünf Sichtweisen (Unternehmenssicht, Informationssicht, Systemsicht, Konstruk‐

tionssicht, Technologiesicht) als Methode zur Betrachtung objektbasierter Systeme an. 

Weitere Erläuterungen zu den genannten Konzepten und Methoden befinden sich im Anhang. 

 14  Grundlagen der Studie 

IT­Systeme: ein Kurzüberblick 

Die im vorangegangen Abschnitt kurz referenzierten Architekturkonzepte bilden die grundlegende Basis 

für Konzeption und Realisierung von E‐Government‐Systemen auf allen Ebenen der Verwaltung. Auch bei 

Kenntnis  dieser  sehr  umfassenden  Konzepte  und  vielfältigen  Standards  ist  es  nicht  einfach,  konkrete  

E‐Government‐Lösungen  auf Basis dieser Vielzahl  relevanter Architekturprinzipien  aufzubauen. Neben 

der Frage "Wo soll man beginnen?" und der damit verbundenen  individuellen Definition von Einstiegs‐

punkten sind deshalb weitergehende konzeptionelle Ansätze erforderlich, um aufbauend auf den grund‐

legenden SOA‐Prinzipien  iterativ und effizient  interoperable prozessorientierte  IT‐Lösungen zu  realisie‐

ren und bewährte Altsysteme (meist Fachanwendungen), Datenbestände und die erforderlichen Nutzer‐

schnittstellen  über  entsprechende  Schnittstellen  und  Integrationskomponenten  zu  integrieren.  Das 

Fraunhofer‐Institut  FOKUS  stellt mit  dem  Fraunhofer  FOKUS  E‐Government‐Labor  eine  Plattform  zur 

Verfügung,  die  gleichzeitig Werkstatt,  Schaufenster  und  Kompetenzknoten  für  zukunftsweisendes  E‐

Government in Deutschland und Europa ist. Als hersteller‐, technologie‐ und produktunabhängiger Part‐

ner  fördert  das  Fraunhofer‐Institut  FOKUS  in  seinem  E‐Government‐Labor  die  Erfolgsfaktoren  für  die 

moderne Verwaltung durch die Entwicklung einer Referenzarchitektur, welche in enger Zusammenarbeit 

mit  zahlreichen  Standardisierungsgremien  und  Verwaltungen  auf  Bundes‐,  Landes‐,  kommunaler  und 

europäischer  Ebene, mit  den  Herstellern  von  E‐Government‐  und  Open‐Source‐Lösungen  sowie  ver‐

schiedenen Forschungsinstituten entstanden  ist und ständig weiter entwickelt wird. Auf Grundlage der 

bisherigen Erfahrungen wurde ein grobes "Computational Model" (im Sinne von RM‐ODP) für eine anzu‐

strebende  E‐Government‐Gesamtarchitektur  entwickelt.  Die  groben  Elemente  (Themenfelder)  dieser 

Referenzarchitektur sind in der folgenden Abbildung dargestellt: 

 

Abbildung 1 ‐ Themenfelder der Fraunhofer FOKUS E‐Government‐Referenzarchitektur 

Weitere Informationen zu den einzelnen Themenfeldern befinden sich im Anhang. 

  15Auswahl von IT‐Systemen 

Auswahl von IT­Systemen 

Vorgehen zur Auswahl / Auswahlprozess 

Im Folgenden werden die einzelnen,  im Kriterienkatalog  referenzierten Methoden und Standards kurz 

erläutert. Die  Kriterien  orientieren  sich  stark  an  den  vorgegebenen  strategischen  Zielen  und wurden 

nach diesen strukturiert. Eine besondere Stellung nimmt hierbei der erste Punkt „Systemanalyse“ ein, da 

die hier erarbeiteten Modelle Grundlage für die meisten der folgenden Fragen zu den Auswahlkriterien 

sind. 

Das Vorgehen zur Auswahl bedeutet in erster Linie die Abarbeitung der Matrix und das Entwickeln einer 

entsprechenden Gewichtung. Es ist abhängig von der Situation und der auszuwählenden Software nicht 

zwingend notwendig alle vorgeschlagenen Methoden  im Ganzen durchzuführen. Wenn auf bestimmte 

Maßnahmen und Prüfungen verzichtet wurde, sollte dies aber ausreichend begründet werden. 

Eine Gewichtung  ist sowohl für  jede einzelne Fragestellung als auch für die thematischen Blöcke vorge‐

sehen. Die Summe der Gewichtungsanteile muss jeweils innerhalb der Blöcke und für die Gesamtgewich‐

tung  immer 100 Prozent ergeben. Überprüft werden kann dies anhand der Kontrollfelder. Eine gleich‐

mäßige Verteilung ohne besondere Schwerpunkte wäre beispielsweise bei 10 Themenblöcken eine  je‐

weilige Gewichtung von 10 Prozent. Die Bewertung erfolgt mit einer Punktevergabe zwischen 0 und 10. 

Das Ergebnis liegt ebenfalls immer zwischen 0 und 10 Punkten. 

 

Abbildung 2 ‐ Beispiel: Kontrollwert, Punktezahl und Gewichtung eines Themenblocks 

   

 16  Auswahl von IT‐Systemen 

Herleitung der Auswahlkriterien 

Systemanalyse 

In  diesem  Abschnitt  wird  ein  allgemeines  Vorgehensmodell  der  Systemanalyse  beschrieben,  das  als 

Grundlage  für  erfolgreiche  Softwareeinführungsprojekte  gewertet  werden  kann.  Ausgehend  von  der 

Zielstellung wird zuerst der IST‐Zustand erfasst, in Modellen dokumentiert und analysiert, um daraus auf 

Basis der SOLL‐Modelle ein geeignetes Fachkonzept zu entwickeln. Das hier beschriebene Vorgehensmo‐

dell nach Krallmann  (Hermann Krallmann, 2007) strukturiert und erläutert die zeitlichen und  logischen 

Aufgaben, die Ziele einzelner Aktivitäten und die dabei anzuwendenden Methoden. Die Systemanalyse 

sollte als Projekt organisiert und durchgeführt werden. 

 

Abbildung 3 ‐ Fünf Phasen der Systemanalyse nach Krallmann, Quelle: (Hermann Krallmann, 2007) 

Die  fünf  Phasen  der  Systemanalyse  Projektbegründung,  Ist‐Analyse,  Soll‐Konzept, Realisierung,  Imple‐

mentierung werden nicht starr durchlaufen, sondern als ein iterativer (wiederholtes Ausführen einzelner 

Phasen),  rückgekoppelter  (Überprüfung von Wirkzusammenhängen), heuristischer Prozess verstanden. 

Das Projektmanagement und Möglichkeiten  zur Mitarbeiter‐Partizipation  (Information und Mitbestim‐

mung) unterstützen den Prozess der Systemanalyse. 

   

  17Auswahl von IT‐Systemen 

Die erste Phase des Vorgehensmodells nach Krallmann ist die Projektbegründung, welche alle Aktivitäten 

zur Initialisierung eines Projekts umfasst. Dazu gehören: 

• Zielanalyse 

• Abgrenzung des zu untersuchenden Systems 

• Projektplanung (z. B. bezüglich erforderlicher Ressourcen, Kosten und Ergebnisse) 

• Prüfung rechtlicher Rahmenbedingungen 

Die  folgenden Grafiken  zeigen Auszüge der Bewertungsmatrix aus dem Abschnitt Systemanalyse. Eine 

Gewichtung und Bewertung  in diesem Abschnitt  ist nicht möglich, da es sich um die Abfrage vorberei‐

tender Maßnahmen handelt. 

 

Abbildung 4 ‐ Auszug aus der Bewertungsmatrix: Systemanalyse 

Die zweite Phase, die Ist‐Analyse, gliedert sich in Ist‐Erfassung, Ist‐Dokumentation und Potenzialanalyse. 

Mit Fokussierung auf den Untersuchungszweck, also die Zielstellung wird in der Ist‐Erfassung der quanti‐

tative und qualitative  Ist‐Zustand des abgegrenzten Systems aufgenommen. Die  Ist‐Erfassung kann auf 

die Erfassung von Zielen, Strukturen, Elementen,  formalen und  informalen Prozessen, Arbeitsabläufen, 

Tätigkeiten, Informationsbedarfen, Entwicklungstendenzen und Anforderungen an das System gerichtet 

sein. Methodisch  kommen  dabei  die  Inventurmethode  (Studium  vorhandener Unterlagen),  die  Inter‐

viewmethode, die Fragebogenmethode oder die Berichtsmethode zum Einsatz. 

Die Ergebnisse aus der Ist‐Erfassung werden in der Phase der Ist‐Dokumentation schriftlich fixiert und in 

Modellen formalisiert. Dafür können verschiedene Modellarten verwendet werden, die alle unterschied‐

liche Ausrichtungen und Anforderungen an die zu erhebenden Daten mit sich bringen. Je nach gewähl‐

 18  Auswahl von IT‐Systemen 

tem Untersuchungsziel und verwendeter Modellart sind verschiedene Erhebungsmethoden besser oder 

schlechter dafür geeignet die nötigen Informationen zu erfassen.  

Folgende Modelle können für die Aufnahme des Ist‐Zustandes herangezogen werden: 

• UML – Die Unified Modeling Language ist eine der verbreitetesten Sprachen für die Modellierung 

von betrieblichen Anwendungs‐ bzw. Softwaresystemen und deren Prozesse. UML  ist über  ISO 

(ISO/IEC 19501) standardisiert. 

• EPK  ‐ Die Ereignisgesteuerte Prozesskette (EPK)  ist eine grafische Modellierungssprache für Ge‐

schäftsprozesse und basiert auf Ereignissen und Funktionen. 

• PICTURE –  Ist eine verständliche und spezifisch  für die öffentliche Verwaltung entwickelte Pro‐

zessbeschreibungssprache, die auf vorgefertigten Prozessbausteinen  (Bsp.: „Formelle Prüfung“, 

„Vorgang weiterleiten“ oder „Rückfrage“) basiert. 

• BPMN ‐ Die Business Process Modeling ist eine grafische Spezifikationssprache der Wirtschaftsin‐

formatik für Geschäftsprozesse und Arbeitsabläufe. 

 

Abbildung 5 ‐ Auszug aus der Bewertungsmatrix: IST‐Analyse 

Die  Ist‐Erfassung sollte nicht auf Schwachstellen  fixiert durchgeführt werden, um eine unvoreingenom‐

mene Systemaufnahme zu ermöglichen. Zum Zeitpunkt der  Ist‐Erfassung  ist noch nicht festgelegt, wel‐

che Fakten zur Begründung von Vorschlägen des Sollkonzepts herangezogen werden müssen. Die erho‐

benen Fakten werden erst in der Potenzialanalyse mit Blick auf die eigentliche Zielrichtung kritisch analy‐

siert, um Schwachstellen zu  identifizieren. Die sich abzeichnenden Verbesserungsmöglichkeiten können 

  19Auswahl von IT‐Systemen 

beispielsweise  in  organisatorische,  informationelle,  technische  und  sonstige  Potenziale  kategorisiert 

werden. 

In  der  kreativen  Phase  der  Sollkonzeption werden  verschiedene  alternative  Konzepte  zur  Lösung  der 

Schwachstellen entworfen. Der Schwerpunkt dieser Phase liegt auf der Konzeption bzw. der Planung von 

organisatorischen,  technischen  und motivatorischen Maßnahmen,  die  in  der  Phase  der  Realisierung 

entwickelt und in der Phase der Implementierung eingeführt werden. Die technischen Maßnahmen soll‐

ten als Basis für die folgende Realisierung in einem detaillierten Pflichtenheft ausgearbeitet werden.  

 

Abbildung 6 ‐ Auszug aus der Bewertungsmatrix: Sollkonzept 

In der Phase der Realisierung wird mit Hilfe der Make‐or‐Buy Analyse über das weitere Vorgehen bei der 

Einführung der neuen Software entschieden, ob Standardsoftware bei einem Hersteller gekauft werden 

soll oder eine eigene Lösung entwickelt wird. In der Praxis sind dabei Zwischenformen denkbar, z. B. die 

Konfiguration und Erweiterung bereits laufender Software. 

 

Abbildung 7 ‐ Auszug aus der Bewertungsmatrix: Realisierung 

Im Falle der Entscheidung zur Neuanschaffung von Software schließt sich im Rahmen der Realisierung ein 

Softwareauswahlprozess an, der mit Hilfe des vorliegenden Kriterienkataloges unterstützt wird.  In der 

Implementierungsphase wird die neue  Lösung  installiert und  konfiguriert  (bzw.  selbst entwickelt) und 

das Sollkonzept schließlich in den Realbetrieb überführt. (Hermann Krallmann, 2007) 

 20  Auswahl von IT‐Systemen 

Wirtschaftlichkeit 

Die Betrachtung der Wirtschaftlichkeit der zu beschaffenden Lösung unterteilt sich in drei Bereiche 

• Anschaffung und Betrieb – ökonomische Betrachtung von Investitionsvorhaben der öffentlichen 

Verwaltung 

• Kostenreduzierung – Betrachtung der Prozesskostenersparnisse durch die Einführung der neuen 

Lösung 

• Nachnutzung – Betrachtung der Möglichkeiten, die Lösung zur Nutzung durch andere bereit zu 

stellen oder fremde Lösungen mit zu nutzen 

Anschaffung und Betrieb 

Als Grundlage für die ökonomische Betrachtung von Investitionsvorhaben wird das Verfahren WiBe vor‐

geschlagen. WiBe bietet methodische und inhaltliche Hilfestellungen für Investitionsverantwortliche, um 

zu begründeten und nachvollziehbaren Aussagen zur Wirtschaftlichkeit von IT‐Investitionen zu gelangen. 

WiBe bietet einen einheitlichen methodischen Rahmen mit folgenden Schwerpunkten: 

• "WiBe KN  ‐ Kosten und Nutzen"‐ monetäre Vorteilhaftigkeit der  Investition ermittelt. Ebenfalls 

können  in diesem Modul Unsicherheiten  in  Form  von Risikozuschlägen berücksichtigt werden 

("WiBe KN/R") 

• "WiBe D ‐ Dringlichkeitskriterien" – Ermittlung der Ablösedringlichkeit von Altsystemen 

• "WiBe Q  ‐ Qualitativ‐strategische Kriterien" ‐ Ermittlung und Bewertung qualitativ‐strategischer 

Kriterien 

• "WiBe E ‐ Externe Effekte" – Ermittlung und Bewertung externer Effekte 

WiBe unterscheidet zwischen quantitativen und qualitativen Kriterien zur Bewertung eines Investitions‐

vorhabens.  In einer  Kosten‐ und Nutzenanalyse wird  auf Basis der Kapitalwertmethode die monetäre 

Vorteilhaftigkeit  ermittelt. Durch die  Einbindung  von Risikozuschlägen  können Unsicherheiten  einfach 

berücksichtigt werden. Mit Hilfe einer Nutzwertanalyse werden neben der monetären Vorteilhaftigkeit 

die qualitativen Wirkungen des Investitionsvorhabens bewertet. 

Bestimmte Fragestellungen aus WiBe, speziell zu den externen Effekten, decken sich mit Fragestellungen 

aus  dem  Kriterienkatalog  von  Fraunhofer  FOKUS  und  können  zur  Beantwortung  dieser  hinzugezogen 

werden. (Peter Röthig) 

Eine Konkretisierung und Prüfung der rechtlichen Anforderungen und Rahmenbedingungen bei der Aus‐

wahl  einer  neuen  Lösung  bietet  die Methode  KORA  (Konkretisierung  rechtlicher  Anforderungen)  der 

  21Auswahl von IT‐Systemen 

Provet (Projektgruppe verfassungsverträgliche Technikgestaltung). Zur Durchführung von KORA werden 

zunächst einschlägige  rechtliche Anforderungen aus der Verfassung oder weiteren Rechtsvorgaben ge‐

sammelt. Aus diesen werden Kriterien abgeleitet und beurteilt, inwieweit die rechtlichen Anforderungen 

erfüllt werden. Ein Beispiel wäre die Realisierung  von Datensparsamkeit des  technischen  Systems  zur 

Verwirklichung  informationeller  Selbstbestimmung. Auf der nächsten  Stufe werden  technische Gestal‐

tungsziele  entworfen.  Aus  der Diskussion  der  Ziele mit  den  technischen  Entwicklern  entstehen  dann 

technische Gestaltungsvorschläge. Die so entwickelte Technik weist eine hohe Rechtsverträglichkeit auf, 

da sie die Ziele der rechtlichen Vorgaben berücksichtigt und fördert. (Schwenke, 2006) 

Die  folgende Grafik  zeigt die  Fragestellungen der Bewertungsmatrix bezüglich Anschaffung & Betrieb, 

sowie eine beispielhafte Gewichtung und Bewertung dieser: 

 

Abbildung 8 ‐ Auszug aus der Bewertungsmatrix: Anschaffung und Betrieb

   

 22  Auswahl von IT‐Systemen 

Kostenreduzierung 

Die Kostenreduzierung bezieht sich auf Prozesskostenersparnisse, die durch den Einsatz der angestreb‐

ten Softwarelösungen ermöglicht werden. Eine optimale Unterstützung der Prozesse durch  IT bedeutet 

beispielsweise: 

• schnellere Bearbeitung und kürzere Liegezeiten (Zeitersparnis)  

• Vermeidung von Medienbrüchen (Materialersparnis) und redundanter Datenerfassung 

Eine Möglichkeit zur Ermittlung der Einsparpotentiale bietet der vom Fraunhofer‐Institut für Arbeitswirt‐

schaft  und  Organisation  (IAO)  entwickelte  eGov‐Rechner.  Der  eGOV‐Rechner  ist  ein  Open‐Source‐

Werkzeug  zur Kosten‐Nutzen‐Analyse bei der Umstellung  klassischer Verwaltungsprozesse  auf digitale 

Geschäftsprozesse. Zielstellung der Anwendung des eGov‐Rechners ist die monetäre Bewertung der Vor‐

teile  von  E‐Government,  die  sich  als  Transformationseffekt  pro  Prozess  in  Euro  darstellt.  Die  Open‐

Source‐Lizenzierung erlaubt die Nutzung des Werkzeugs zur eigenständigen Berechnung von digitalisier‐

ten  Geschäftsprozessen  sowie  die  Anpassung,  Weiterverteilung  und  Vervielfältigung  der  Software. 

(Fraunhofer IAO, 2007) 

 

Abbildung 9 ‐ Auszug aus der Bewertungsmatrix: Kostenreduzierung 

   

  23Auswahl von IT‐Systemen 

Nachnutzung 

Die Nachnutzung bezieht  sich auf die Replikation oder Mit‐Nutzung der  Lösung  in Bezug auf Prozesse 

oder Teilprozesse. Die Fragestellung ist, ob die angestrebte Lösung auch für andere Bereiche der öffentli‐

chen Verwaltung bereitgestellt oder  von diesen bezogen werden  kann. Der Einsatz  von Open‐Source‐

Software bietet hier durch die erheblichen Einspareffekte bei den Lizenzkosten erhebliche Vorteile bei 

der Nachnutzung. Beispielsweise könnte die Lösung im Rahmen eines „Software‐as‐a‐Service“ Distributi‐

ons‐Modells  auf  der  Dienstplattform  des  ITDZ  angeboten  werden.  (Till  Jaeger,  2006)

 

Abbildung 10 ‐ Auszug aus der Bewertungsmatrix: Nachnutzung 

   

 24  Auswahl von IT‐Systemen 

Kundenorientierung 

Die Kundenorientierung  in Bezug auf Verwaltungsprozesse und die eingesetzte  IT umfasst mehrere As‐

pekte. Neben der allgemeinen Verbesserung der Qualität aus Kundensicht  (Bürger und Unternehmen), 

bedingt durch kürzere Prozesslaufzeiten und die Vermeidung von Stellen2‐ und Medienbrüchen, sind die 

Barrierefreiheit  und  die  Bereitstellung  verschiedener  Zugangswege  im  Sinne  einer  Multi‐Kanal‐

Architektur von großer Bedeutung (Lucke, 2007). 

Für Bürger sind Kontakte mit der Verwaltung oft kompliziert. Dennoch sind diese Kontakte nicht gänzlich 

vermeidbar, da öffentlich Leistungen benötigt werden oder in bestimmten Situationen unabdingbar sind. 

Die Komplexität hat für den Bürger dabei verschiedene Ursachen. So sind die Kontakte häufig mit einem 

größeren im Vorfeld nicht genau zu bestimmenden Zeitaufwand verbunden. Zusätzlich sorgt die Unwis‐

senheit über die genauen Bestimmungen und Erfordernisse  für unliebsame Überraschungen. Verzöge‐

rungen bei Beantragung und Bearbeitung können für den Bürger zudem Probleme und Folgekosten nach 

sich ziehen. Doch auch bei Anträgen, die keinen akuten zeitlichen Druck haben, sind Verzögerungen läs‐

tig, da sie stets das Gefühl hinterlassen, dass man noch eine unangenehme Pflichtaufgabe erfüllen müs‐

se. Neben finanziellen Schäden und zeitlichem Aufwand spielt für den Bürger damit auch eine emotiona‐

le Komponente eine Rolle. 

Das bei Bürgern vorherrschende Gefühl der Komplexität wird bei Unternehmen von einem klaren Kos‐

tenkalkül dominiert. Neben den direkt mit einer Verwaltungsleistung verbundenen Kosten spielen auch 

indirekte Kosten und entgangene Erlöse eine Rolle. Es werden also nicht nur die Kosten für die Antrags‐

stellung, Dokumentenbeschaffung  (z. B. beglaubigte Kopien, Handelsregisterauszug, etc.) mit einbezo‐

gen, sondern auch Nebenkosten. Hierunter fallen: 

• Lohnkosten auf Vollkostenbasis für die Zeit, die Mitarbeiter mit der Beantragung verbringen 

• Fahrtkosten für die Wege zum Amt 

• Büromittel‐, Kommunikations‐ und Portokosten 

Ferner werden Opportunitätskosten  einbezogen,  die  aus  Verzögerungen  bei  der  Antragsstellung  und 

Genehmigung entstehen können (z. B. fehlende Umsätze durch verspätete Betriebserlaubnisse, höhere 

Refinanzierungskosten durch verzögerte Zahlungen). 

                                                            2  Stellenbruch  – Aufteilung  einer  logisch  zusammenhängenden Aufgabe  auf  verschiedene  bearbeitende  Stellen, wobei zusätzliche Arbeitsaufwände und Fehlerquellen entstehen können 

  25Auswahl von IT‐Systemen 

Auch für Unternehmen gilt, dass Verwaltungsleistungen für sie nur Bestandteil größerer Leistungsbündel 

oder komplexerer Arbeitsabläufe sind. Beispiele sind die benötigten Führungszeugnisse und Handelsre‐

gisterauskünfte  bei der Bewerbung  auf  öffentliche Ausschreibungen,  oder  die  Sozialversicherungsleis‐

tungen im Rahmen des Personalmanagements.  

Speziell bei Online‐Dienstleistungen ist für den Bürger die Barrierefreiheit der jeweiligen Anwendung ein 

entscheidender Aspekt. Die Barrierefreiheit gilt für Menschen mit und ohne Behinderungen gleicherma‐

ßen und  schließt Benutzer mit  technischen oder altersbedingten Einschränkungen mit ein. Viele Men‐

schen mit  Behinderungen  suchen Online  nach Dienstleistungen  Ihrer  Verwaltung  und  sind  daher  auf 

speziell  aufbereitete Webangebote  angewiesen. Beispielsweise  lassen  sich Blinde  oder  sehbehinderte 

Nutzer Webseiten per Software vorlesen oder in Braille‐Schrift ausgeben und für gehörlose oder schwer‐

hörige Menschen, deren erste Sprache Gebärdensprache  ist, gibt es besondere auf sie zugeschnittene 

Darstellungsformen für Webseiten. 

Die technische Barrierefreiheit sorgt dafür, dass Webangebote mit verschiedenen Hard‐ und Software‐

konfigurationen  gleichermaßen  genutzt  werden  können,  beispielsweise  bei  der  Verwendung  unter‐

schiedlicher Betriebssysteme und Webbrowser. Gewissermaßen spielt hierbei auch die Schaffung alter‐

nativer  Zugangswege  im  Sinne  einer Multi‐Kanal‐Architektur  eine  Rolle. Dienstleistungen  der  öffentli‐

chen Verwaltung sollten keinesfalls ausschließlich Online verfügbar sein, daraus ergibt sich die Anforde‐

rung auch einen Wechsel der Zugangskanäle  im  laufenden Prozess zu ermöglichen  (Prozesse, die über 

das Internet initiiert wurden, über das Telefon fortzuführen, etc.). 

Verschiedene Initiativen und Gesetze haben zum Ziel, das Web barriereärmer zu gestalten: 

• Web  Accessibility  Initiative  (WAI)  vom W3C  veröffentlichte  1999  den  ersten  internationalen 

Standard „Web Content Accessibility Guidelines 1.0“  (WCAG  ‐ aktuelle Version WCAG 2.0[2][3] 

vom 11. Dezember 2008) 

• Die eEurope‐Initiative  (Dezember 1999) Einführung der Richtlinien der WAI bis 2002  in der öf‐

fentlichen Verwaltung und Design‐for‐All‐Standards bis 2003.  

• Behindertengleichstellungsgesetz – BGG  in Deutschland – die Bundesverwaltung wird verpflich‐

tet, ihre öffentlich zugänglichen Internet‐ und Intranet‐Angebote barrierefrei zu gestalten. 

• Rechtsverordnung Barrierefreie Informationstechnik‐Verordnung – BITV vom Bundesinnenminis‐

terium und Bundesministerium für Arbeit und Soziales regelt die Maßgaben nach dem Behinder‐

tengleichstellungsgesetz 

 26  Auswahl von IT‐Systemen 

• Im Aktionsbündnis  für barrierefreie  Informationstechnik – Zusammenschluss von Behinderten‐

verbänden, Forschungseinrichtungen und Anderen zur Förderung der Barrierefreiheit  im  Inter‐

net.  Jährliche  Auszeichnung  der  besten  deutschsprachigen,  barrierefreien Websites mit  dem 

BIENE‐Award. 

Folgende Fragestellungen sind zu diesem Thema in der Matrix enthalten: 

 

Abbildung 11 ‐ Auszug aus der Bewertungsmatrix: Kundenorientierung 

   

  27Auswahl von IT‐Systemen 

Beschäftigungsorientierung 

Im Sinne der Beschäftigungsorientierung gilt es zum einen, die aufgenommenen Mitarbeiterprozesse auf 

Potentiale  zur Arbeitserleichterung bzw.  zur Vermeidung  von unnötigem Aufwand  zu  analysieren und 

zum anderen die Softwareergonomie der angestrebten Lösung zu überprüfen. Die zentrale Fragestellung 

ist, ob sich die Arbeitsabläufe aus Sicht der Mitarbeiter vereinfachen/verbessern oder komplizierter wer‐

den und sich dadurch verschlechtern.  

Beispiele für zu vermeidende Schwachstellen bei der Betrachtung von Mitarbeiterprozessen sind: 

• Taylorismus – rein mechanische Sichtweise auf Betriebsabläufe und Strukturierung (Entstehung 

überflüssiger Stellenbrüche) 

• Doppelarbeiten (Redundanzen) 

• Medienbrüche – resultieren in Mehrfacheingaben derselben Datensätze 

• Schlechter Nutzungsgrad der IT‐Ressourcen – kaum IT‐Unterstützung bei der täglichen Arbeit 

• Arbeit mit unterschiedlichen Anwendungen/Dateitypen: Beispielsweise bei der Einführung neuer 

Office‐Anwendungen. 

Software‐Ergonomie als Teilgebiet der Mensch‐Computer‐Interaktion zielt darauf ab, benutzerfreundli‐

che und gebrauchstaugliche Software zu entwickeln. Für die Gestaltung von Software an Bildschirmar‐

beitsplätzen  gibt  es  formale  Richtlinien wie  die  Bildschirmarbeitsverordnung  (BildscharbV)  sowie  den 

Standard ISO 9241 der Internationalen Organisation für Normung. 

Folgende Richtlinien sind darin festgehalten und sollten somit bei der Auswahl, speziell von Anwendun‐

gen mit hoher Benutzerinteraktion, berücksichtigt werden: 

• Konsistenz der Benutzerführung 

• Ständige Verfügbarkeit der Rechtschreibprüfung 

• Unmittelbare Verständlichkeit der Benutzerführung 

• Automatisierung sich wiederholender Aufgaben 

• Umgehende Rückmeldung an den Benutzer 

• Selbsterklärungsfähigkeit 

• Anpassbarkeit an individuelle Bedürfnisse 

• Fehlertoleranz (Undo‐Funktion) 

• Erwartungskonformität 

• Höflichkeit 

 28  Auswahl von IT‐Systemen 

 

Abbildung 12 ‐ Auszug aus der Bewertungsmatrix: Beschäftigungsorientierung 

 

Herstellerunabhängigkeit 

Die zu starke Konzentration auf ein Produkt oder einen Hersteller in bestimmten funktionalen oder fach‐

lichen Bereichen birgt Risiken, wenn es um die Ablösung eines  Softwareprodukts geht. Der Hersteller 

befindet  sich durch potentielle, hohe Migrationskosten,  verursacht durch mangelnde  Interoperabilität 

mit  anderen  Softwareprodukten  in  einer  starken Verhandlungsposition.  Schwerwiegende  Folgen  kann 

auch der Wegfall eines Lieferanten haben. Vorteilhaft sind Produkte, die von verschiedenen Anbietern 

und Dienstleistern angeboten und unterstützt werden, da hier der Wegfall eines Dienstleisters  leichter 

kompensiert werden kann und eine Herstellerunabhängigkeit gesteigert wird. Dies ist beispielsweise bei 

vielen Open‐Source Produkten der Fall. Trotzdem ergeben sich auch Vorteile aus der Bindung an einen 

Hersteller, beispielsweise hohes, branchenspezifisches „Vor‐Ort‐Wissen“ bei den Mitarbeitern der Ver‐

waltung sowie die Nachnutzungsmöglichkeiten von bereits getätigten Vorinvestitionen und Integrations‐

vorteile innerhalb der herstellereigenen Produktfamilie. Folgende Punkte sollten daher zwingend Gegen‐

stand einer Überprüfung der angestrebten Lösung sein: 

  29Auswahl von IT‐Systemen 

• Prüfung von möglichen Produkt‐ und/oder Dienstleisteralternativen, um sich gegenüber den  je‐

weiligen Anbietern in eine bessere Verhandlungsposition zu bringen. Das gilt sowohl für die An‐

schaffung  als  auch  später  für  eventuelle  Dienstleistungen,  Anpassungen,  Erweiterungen  oder 

Updates. 

• Das konsequente Aufsetzen auf Berliner IT‐Standards und die Orientierung an SAGA, sowie XÖV 

ermöglicht zum einen eine höhere Kompatibilität mit anderen Lösungen, zum anderen eine ge‐

ringere Bindung an den Hersteller, da die Lösungen im Zweifelsfall austauschbar sind. 

• Vermeidung von Abhängigkeiten zu Betriebssystemherstellern. Bei einem späteren Wechsel von 

Betriebssystemen sollten die Anwendungen nicht betroffen sein. 

• Prüfung der technischen Abhängigkeiten. Setzt das gewünschte System explizit nur ein Produkt 

eines Herstellers voraus, besteht die Gefahr einer geschwächten Verhandlungsposition gegen‐

über diesem.  (Bsp.: Datenbankunterstützung: Bei einem späteren Wechsel der DB‐Technologie 

sollten die Anwendungen nicht betroffen sein und verschiedene Produkte unterstützen.) 

Eine Hilfestellung bei der Einordnung der zu beschaffenden Lösung und der Identifikation von Abhängig‐

keiten bietet die Fraunhofer FOKUS Referenzarchitektur für E‐Government. 

 

Abbildung 13 ‐ Auszug aus der Bewertungsmatrix: Herstellerunabhängigkeit 

   

 30  Auswahl von IT‐Systemen 

Vernetzung 

Unter dem Kriterium Vernetzung stellt sich die Frage, ob durch die Einführung einer neuen Lösung eine 

schnelle, unkomplizierte und zuverlässige Zusammenarbeit von Berliner Behörden unterstützt wird.  Im 

Fokus stehen dabei eher einfache Lösungen wie eine gemeinsame Wissensplattform (Stichwort: Telefon‐

verzeichnis). Im Einzelfall sollte also geprüft werden, in wie weit die angestrebte Lösung eine solche Zu‐

sammenarbeit  unterstützt  oder wie  diese  durch  einfache  aber  gezielte  organisatorische Maßnahmen 

unterstützt werden kann. 

Der folgende Tabellenausschnitt zeigt den entsprechenden Abschnitt aus der Bewertungsmatrix.  

 

Abbildung 14 ‐ Auszug aus der Bewertungsmatrix: Vernetzung 

   

  31Auswahl von IT‐Systemen 

Sicherheit 

Für die Sicherheit von IT‐Systemen in der öffentlichen Verwaltung bietet der IT‐Grundschutz der Bundes‐

regierung eine einfache Methode, dem Stand der Technik entsprechende  IT‐Sicherheitsmaßnahmen zu 

identifizieren und umzusetzen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt zahl‐

reiche Werkzeuge zur Verfügung, um ein angemessenes Sicherheitsniveau zu erreichen, wie zum Beispiel 

die  BSI‐Standards  zum  Informationssicherheitsmanagement,  die  IT‐Grundschutz‐Kataloge  und  das 

GSTOOL. Dazu gehört aber auch die  ISO 27001‐Zertifizierung auf Basis von  IT‐Grundschutz, die sowohl 

eine  Prüfung  des  Informationssicherheitsmanagements,  als  auch  der  konkreten  IT‐

Sicherheitsmaßnahmen auf Basis von IT‐Grundschutz umfasst. 

Die  IT‐Grundschutz‐Kataloge  vereinen  Informationen und Dokumente des BSI, die der Erkennung und 

Vermeidung sicherheitskritischer Schwachstellen in IT‐Umgebungen (IT Verbund) dienen. Die Erkennung 

und Bewertung dieser  Schwachstellen erfolgt normalerweise über eine Risikoanalyse, wobei  für  jedes 

System oder jede Systemklasse einzeln das entsprechende Gefährdungspotential geschätzt und potenti‐

elle Schadkosten ermittelt werden. Dies  ist eine  zeitaufwendige und  teure Herangehensweise. Der  IT‐

Grundschutz dagegen geht von einer für das System standardisierten Gefährdungslage aus, die in einem 

Großteil der Fälle zutreffend ist, und stellt entsprechende Gegenmaßnahmen bereit. Das somit erreichte 

Sicherheitsniveau wird in den meisten Fällen als zureichend betrachtet und erspart somit die teure Risi‐

koanalyse. Der IT‐Grundschutz stellt im Falle eines höheren Sicherheitsbedarfes entsprechend weiterfüh‐

rende Maßnahmen bereit. 

Eine Sicherheitsprüfung nach Kriterien des IT‐Grundschutzes des BSI ist dringend zu empfehlen. 

 

Abbildung 15 ‐ Auszug aus der Bewertungsmatrix: Sicherheit 

 

Zukunftsfähigkeit 

Die Prüfung der  Zukunftsfähigkeit der  angestrebten  Lösung  sollte  zum einen darauf  abzielen, wie die 

Position des Herstellers und Produktes am Markt zu bewerten ist und in wie weit sich die Lösung auch in 

zukünftigen Prozess‐ und dienstorientierten Architekturen integrieren und skalieren lässt. 

 32  Auswahl von IT‐Systemen 

Die Prüfung der Zukunftsfähigkeit des Herstellers und der Produktgruppe lässt sich mit Hilfe einer Markt‐

analyse und Herstellerbefragung hypothetisch beurteilen. Wichtig dabei  ist, ob der benötigte  Support 

langfristig ausreichend gewährleist werden kann. Kriterien für die hypothetische Beurteilung der zukünf‐

tigen Entwicklung eines Herstellers sind: 

• Das Unternehmen befindet sich nicht in Insolvenz 

• Das Unternehmen ist hinreichend versichert (bspw. Haftpflicht) 

• Zahl der Beschäftigen Produktion/Support 

• Marktanteile des Herstellers/Produktes 

• Offenlegung/Sicherungsmechanismen bei Insolvenz 

• Verfügbarkeit als Open‐Source‐Software 

Für die Zukunftsfähigkeit der Lösung im Rahmen der eigenen Gesamtarchitektur muss beurteilt werden, 

wie sie sich in eine zukunftsweisende Softwarearchitektur (z. B.: SOA) integrieren lässt. Die Frage ist, ob 

genügend Schnittstellen vorhanden sind, um bereits vorhandene oder zukünftig zu beschaffende Syste‐

me mit der angestrebten Lösung zu koppeln. Dazu gehört bspw. auch die Einbindung von Plattformdiens‐

ten wie  sie auf der Dienstplattform des  ITDZ angeboten werden. Hilfestellung  für die Einordnung der 

Lösung in die Gesamtarchitektur gibt das Referenzmodell für SOA. 

Ein wichtiger zu prüfender Punkt  ist die Skalierbarkeit der Lösung, falls ein zukünftig wachsendes Men‐

gengerüst die Leistungsanforderungen erhöht. 

 

Abbildung 16 ‐ Auszug aus der Bewertungsmatrix: Zukunftsfähigkeit 

   

  33Auswahl von IT‐Systemen 

Regionale Förderung 

Durch  die  Einführung  leistungsfähiger  und  effizienter  E‐Government‐Lösungen  wird  der Wirtschafts‐

standort Berlin gestärkt. Einfach und schnell von Unternehmen zu nutzende E‐Government‐Leistungen 

sind ein  immer grösser werdender Vorteil  in einem  zunehmenden  Standortwettbewerb  zwischen den 

Regionen. Die Wirtschaftsregion kann weiterhin gefördert werden, indem bei der Beschaffung von Soft‐

warelösungen  besonders  lokale  Hersteller  und  Supportdienstleister  berücksichtigt  werden.  Dadurch 

werden regionale Arbeitsplätze gesichert oder sogar neue geschaffen, was wiederum die Steuereinnah‐

men erhöht und somit ein Teil der Investitionen in die öffentlichen Kassen zurückfließt. 

 

Abbildung 17 ‐ Auszug aus der Bewertungsmatrix: regionale Förderung 

 34  Fazit und Handlungsempfehlungen 

Fazit und Handlungsempfehlungen 

Die vorliegende Studie  leitet Auswahlkriterien her, die den dezentralen Bereichen bei der Softwarebe‐

schaffung helfen,  indem  sie den Entscheidungsprozess  strukturieren und die einzelnen Entscheidungs‐

schritte unterstützen. Die Studie orientiert sich dabei an den  „Leitgedanken zur IT‐Strategie Berlin“ und 

sorgt damit dafür, dass Entscheidungen möglichst konform sind mit den gesamtstrategischen Zielen. Zu 

diesen Zielen gehört auch die Gleichberechtigung von Open Source Software  im Wettbewerb mit pro‐

prietärer Software. Auch dies wird über die Berücksichtigung der „Leitgedanken zur  IT‐Strategie Berlin“ 

in den Auswahlkriterien reflektiert. 

Die wesentlichen Empfehlungen für die Softwarebeschaffer in den dezentralen Ämtern sind: 

• Die Verwendung der Bewertungsmatrix im Prozess der Softwarebeschaffung 

Die Auswahlkriterien, die  in der Studie hergeleitet und  in der Bewertungsmatrix zusammenge‐

führt wurden, sollten im Softwarebeschaffungsprozess in den dezentralen Bereichen verwendet 

werden. Die Bewertungsmatrix hilft dabei die Qualität der Softwareauswahl zu verbessern, Ent‐

scheidungen  einfacher  kommunizierbar  zu machen  und,  wenn  gewünscht,  Transparenz  und 

Vergleichbarkeit herzustellen. 

 

• Die Nutzung von vorhandenen Beratungs‐ und Kompetenzzentren 

Sowohl das ITDZ als auch das Fraunhofer Institut für offene Kommunikationssysteme bieten der 

Berliner Verwaltung Beratung in IT‐Fragen. Diese Kompetenzen sollte sich die Verwaltung gera‐

de bei komplexeren Fragestellungen  im Rahmen der Beschaffung zunutze machen. Fraunhofer 

FOKUS betreibt dabei mit dem eGovernment‐Labor eine Umgebung, die zur Demonstration ver‐

schiedener Software‐Lösungen, zur Durchführung von  Interoperabilitätstests sowie für die Ent‐

wicklung von Szenarien bis hin zu Prototypen genutzt werden kann. Um speziell die Nutzung von 

Open Source Software zu vereinfachen und dabei bestehende Probleme (z.B. Lizenzkompatibili‐

tät) auszuräumen, wird am Fraunhofer  Institut FOKUS  zudem eine auf Open Source Software 

spezialisierte  Beratung  angeboten.  Für  diesen  Bereich wurde  2009  das Qualipso  Kompetenz‐

zentrum gegründet, das auch auf die BerliOS Expertise zurückgreifen kann. 

 

 

 

  35Fazit und Handlungsempfehlungen 

Zur weiteren Optimierung der eGovernment‐ und IT‐Landschaft in Berlin bieten sich auch auf Landessei‐

te Ansatzpunkte, die im Rahmen der Studie identifiziert wurden: 

• Stärkere Ausdifferenzierung des IT‐Zielbildes für das Land Berlin 

Die stärkere Ausdifferenzierung des IT‐Zielbildes beinhaltet eine Verfeinerung der strategischen 

Vorgaben. Hierbei sollte insbesondere eine auf SOA‐Konzepten basierende Zielarchitektur erar‐

beitet werden.  Einen  Ausgangspunkt  könnte  hier  beispielsweise  die  Referenzarchitektur  von 

Fraunhofer FOKUS bilden. Die Zielarchitektur sollte dabei um eine Roadmap ergänzt werden, die 

die Transformation hin zum Zielbild beschreibt und gangbar macht. 

 

• Unterstützung der dezentralen Beschaffung 

Die dezentrale Beschaffung hat den Vorteil einer engen Kopplung von Bedarf und Beschaffungs‐

vorgang. Diesem Vorteil stehen jedoch einige Nachteile gegenüber, wie die mangelnde Ausnut‐

zung von Skaleneffekten, das Fehlen von speziellem Know‐How, die komplexe Steuerung einiger 

Vergabeverfahren und –formen oder Interoperabilitätsprobleme bei übergreifenden Funktionen 

und Aufgaben. Die  Etablierung  einer  IT‐Governance  könnte die Nachteile  gezielt  adressieren, 

ohne dass die Vorteile der dezentralen Beschaffung verloren gingen. Wichtig wären hierbei ins‐

besondere die Vorgabe von Standards und die Beteiligung an Standardisierungsprozessen, wo‐

bei diese Maßnahmen helfen Interoperabilitätsprobleme zu vermeiden und die Etablierung von 

Querschnittsprozessen und –diensten zu ermöglichen, sowie ein strategischer Einkauf, der die 

dezentrale Beschaffung berät und unterstützt und damit hilft Synergien zu heben.   

 

• Ausnutzen von Stärken des Standortes Berlin 

Der Standort Berlin verfügt insbesondere im eGovernment Umfeld über eine sehr starke Positi‐

on in der deutschen Forschungslandschaft. Das hier vorliegende Potential sollte genutzt werden, 

um  innovative  Lösungen  voranzubringen und Berlin besser  zu positionieren. Eine Möglichkeit 

wäre die bessere Nutzung von  für Onlinedienstleistungen  im Rahmen des neuen Personalaus‐

weises, für den jüngst in Berlin das Kompetenzzentrum CCEPA aufgebaut wurde.  

 36  Literaturverzeichnis 

Literaturverzeichnis 

Alexander Grosskopf, G. D. (2009). The Process: Business Process Modeling Using BPMN. Meghan Kiffer 

Pr. 

Allweyer, T. (2009). BPMN ‐ Business Process Modeling Notation: Einführung in den Standard für die 

Geschäftsprozessmodellierung. Books on Demand. 

Ben Caldwell, M. C. (11. 12 2008). Web Content Accessibility Guidelines (WCAG) 2.0. Abgerufen am 20. 

10 2009 von W3C Recommendation: http://www.w3.org/TR/WCAG20/ 

Benutzungsschnittstellen, G. N. (2009). DIN EN ISO 9241‐129, Ergonomie der Mensch‐System‐Interaktion 

‐ Teil 129: Leitlinien für die Individualisierung von User Interfaces. DIN. 

Bertmann, C., Born, C., Goldau, T., Luch, A., Moukabary, G., Peters, J., et al. (2008). Strategie 115. 

Stuttgart: ibidem. 

Böhle, W., Gollan, L., Lehmann, B., & Rombach, V. (2003). Bewertung von Zahlungssystemen für e‐

Government‐Anwendungen unter kommunalen Gesichtspunkten. Dokumentation >Pilotprojekt e‐

Government NRW< . 

Breitenstrom, C., Brunzel, M., & Klessmann, J. (Dezember 2008). Elektronische Safes für Daten und 

Dokumente. (F. I. (FOKUS), Hrsg.) Berlin. 

Bundesgesetz. (27. 04 2002). Gesetz zur Gleichstellung behinderter Menschen. Abgerufen am 20. 10 

2009 von (Behindertengleichstellungsgesetz‐ BGG): 

http://bundesrecht.juris.de/bundesrecht/bgg/gesamt.pdf 

Bundesverband Deutscher Banken. (2005). Anzahl der Kreditkarten in Deutschland ‐ Statistik‐Service ‐ 

Banken. 

Bundesverordnung. (04. 12 1996). Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an 

Bildschirmgeräten. Abgerufen am 20. 10 2009 von (Bildschirmarbeitsverordnung ‐ BildscharbV): 

http://www.gesetze‐im‐internet.de/bildscharbv/BJNR184300996.html 

Bundesverordnung. (17. 07 2002). Verordnung zur Schaffung barrierefreier Informationstechnik nach 

dem Behindertengleichstellungsgesetz . Abgerufen am 20. 10 2009 von (Barrierefreie 

Informationstechnik‐Verordnung ‐ BITV): http://www.gesetze‐im‐internet.de/bitv/BJNR265400002.html 

  37Literaturverzeichnis 

Fraunhofer IAO. (13. 06 2007). Fraunhofer IAO. Abgerufen am 20. 10 2009 von eGOV‐Rechner: 

http://www.egov‐rechner.org/ 

Gerz, K., & Alfes, K. (2004). Die Kommunalverwaltung auf dem Weg zur Bürgerorientierung. 

Hermann Krallmann, M. S. (2007). Systemanalyse im Unternehmen ‐ Prozessorientierte Methoden der 

Wirtschaftsinformatik. Oldenbourg Wissenschaftsverlag GmbH. 

Hoch, D. J., & Haenecke, H. (2006). IT‐Projekte im offentlichen Sektor aktiv managen statt verwalten. 

Innovative Verwaltung. IT‐Special . 

Höfling, J. (Dezember 2008). Geht mit De‐Mail die E‐Post ab? Staat & IT . 

Informationstechnik, B. f. (2008). IT‐Grundschutz‐Downloads. Abgerufen am 20. 10 2009 von IT‐

Grundschutz‐Kataloge: 

https://www.bsi.bund.de/cln_134/DE/Themen/weitereThemen/ITGrundschutzKataloge/Download/dow

nload_node.html 

Inneres, B. S. (Oktober 2009). Leitegedanken zur IT‐Strategie Berlin. Berlin. 

Innern, B. d. (03 2008). Standards und Architekturen für E‐Government (SAGA). Abgerufen am 20. 10 

2009 von 

http://www.cio.bund.de/cae/servlet/contentblob/77116/publicationFile/3995/saga_4_0_download.pdf 

Irene Teich, W. K. (2007). Der richtige Weg zur Softwareauswahl: Lastenheft, Pflichtenheft, Compliance, 

Erfolgskontrolle. Berlin: Springer. 

Jörg Becker, L. A. (2009). Prozessorientierte Verwaltungsmodernisierung: Prozessmanagement im 

Zeitalter von E‐Government und New Public Management. Berlin: Springer. 

Jörg Becker, M. K. (2008). Prozessmanagement: Ein Leitfaden zur prozessorientierten 

Organisationsgestaltung. Springer. 

Kraftfahrt‐Bundesamt. (Februar 2008). Der Fahrzeugbestand im Überblick am 1. Januar 2008 gegenüber 

1. Januar 2007. 

Lucke, J. v. (2007). Hochleistungsportale für die öffentliche Verwaltung. Eul. 

 38  Literaturverzeichnis 

Markus Nüttgens, F. J. (2002). EPK 2002 ‐ Geschäftsprozessmanagement mit Ereignisgesteuerten 

Prozessketten, Proceedings des GI‐Workshops und Arbeitskreistreffens . Trier: GI‐Arbeitskreis 

Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten 2002. 

Nazemi, F. (2007). Systemanalytische Methoden zur Auswahl von Standardsoftware. Grin Verlag. 

Nitschke, R., Ritter, H., Fischlin, M., & Giessler, M. (Aprill 2005). Authentisierung im E‐Government ‐ 

Mechanismen und Anwendungsfelder der Authentisierung. 

Norbert Bieberstein, R. G. (2008). Executing SOA: A Practical Guide for the Service‐Oriented Architect. 

Prentice Hall International. 

Norbert Bieberstein, S. B. (2005). Service‐Oriented Architecture Compass. Prentice Hall International. 

Object Management Group. (03. 01 2009). Object Management Group/Business Process Management 

Initiative. Abgerufen am 20. 10 2009 von http://www.omg.org/spec/BPMN/1.2/PDF/ 

OECD. (März 2001). The Hidden Threat to E‐Government ‐ Avoiding large government IT failures. PUMA 

Policy Brief No. 8.  

Patrick Grässle, H. B. (2007). UML 2.0 projektorientiert ‐ Geschäftsprozessmodellierung, IT‐System‐

Spezifikation und Systemintegration mit der UML. Galileo Press. 

Peter Röthig, K. B. WiBe 4.1‐ Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der 

Bundesverwaltung, insbesondere beim Einsatz der IT. Berlin: Bundesministerium des Innern (KBSt), 

Schriftenreihe der KBSt. 

Projektgruppe E‐Government im Bundesamt für Sicherheit in der Informationstechnik (BSI). (Mai 2005). 

Sichere Zahlungsverfahren für E‐Government. E‐Government‐Handbuch . 

Redaktion com4biz. (24. September 2007). Was VoIP für Unternehmen wirklich bringt ‐ Vor‐ und 

Nachteile im Vergleich. Von http://www.com4biz.de/wissen/one‐entry?entry_id=8438 abgerufen 

Ross, J. W. (04 2006). Enterprise Architecture: Driving Business Benefits from IT. Abgerufen am 20. 10 

2009 von http://papers.ssrn.com/sol3/papers.cfm?abstract_id=920666 

Royer, D., & Rannenberg, K. (2006). Mobilität, mobile Technologie und Identität ‐ Mobile 

Identitätsmanagementsysteme. DuD ‐ Datenschutz und Datensicherheit (30). 

  39Literaturverzeichnis 

Scheer, A.‐W. (1997). Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. Berlin: 

Springer. 

Schwenke, M. C. (2006). Individualisierung und Datenschutz rechtskonformer Umgang mit 

personenbezogenen Daten im Kontext der Individualisierung. Berlin: Springer. 

Tiemeyer, E. (2007). IT‐Strategien entwickeln. IT Architekturen planen: IT als Wertschöpfungsfaktor. 

Rauscher. 

Till Jaeger, A. M. (2006). Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 

Beck Juristischer Verlag. 

Viola, G. (Februar 2009). An seiner Stimme sollt ihr den Bürger erkennen ‐ Sprachbiometrische Systeme 

in der modernen Verwaltung. 

von Lucke, J. (2008). Hochleistungsportale für die öffentliche Verwaltung. Köln: Josef Eul Verlag. 

Vrdoljak, M., Vrdoljak, S., & Skugor, G. (February 2000). Fixed‐mobile convergence strategy: technologies 

and marketopportunities. Communications Magazine , 2 (38 ). 

Wendy Chisholm, G. V. (05. 05 1999). Web Content Accessibility Guidelines 1.0. Abgerufen am 20. 10 

2009 von W3C Recommendation 5‐May‐1999: http://www.w3.org/TR/WCAG10/ 

 

 40  Anhang 

Anhang 

Terminologie 

Service­orientierte  Architekturen  (SOA)  als  Basis  prozessorientierter  E­Government­

Infrastrukturen 

Die Bezeichnung Service‐orientierte Architektur (SOA) ist mit einem zukunftsweisenden Integrationskon‐

zept verbunden, welches nicht nur verschiedene heterogene  IT Systeme miteinander verbinden kann, 

sondern auch eine engere Kopplung zwischen den fachlichen Anforderungen und dem Einsatz entspre‐

chender Technologie zu deren Unterstützung bietet. Die Loslösung vom rein technischen Integrationsan‐

satz hin zur ganzheitlichen Betrachtungsweise (SOA‐Governance), die eine organisationsweite  fachliche 

und  technologische  Transformation  von  einer  aufgabenorientierten Denkweise hin  zu  einer  stärkeren 

Orientierung auf Prozesse beinhaltet,  ist die eigentlich Neuerung  in Bezug auf klassische technische  In‐

tegrationskonzepte  (z.  B.  EAI).  Technisch  realisiert  werden  Service‐orientierte  Architekturen  auf  der 

Grundlage einer abgestimmten Menge an  internationalen Standards, die bereits von den meisten Her‐

stellern unterstützt werden. Ziel dieser Standards ist es, das Zusammenwirken heterogener Softwaresys‐

teme zur Realisierung übergreifender Geschäftsprozesse zu verbessern, und die heute sehr hohen Integ‐

rationskosten  drastisch  zu  reduzieren.  SOA  basiert  auf  etablierten  Internetprotokollen  und  Informati‐

onsmodellen wie HTTP und XML, ergänzt durch weitere Standards. Ein wesentliches Paradigma ist dabei 

die Serviceorientierung, die es ermöglicht, heterogene IT‐Komponenten über offene Dienstschnittstellen 

"lose" miteinander zu verknüpfen. Die Funktionen, internen Prozessabläufe, Datenformate und ggf. Ser‐

vicekriterien und anfallende Kosten der autonomen Dienste können nach außen bekannt gemacht wer‐

den,  die  Implementierungsdetails  und  internen  Funktionen  der  Komponenten  jedoch  nicht.  Dadurch 

können Funktionen/Dienste plattformunabhängig  in  technische Abläufe eingebunden werden. Mithilfe 

von  Prozessbeschreibungssprachen wie  BPEL  (Business  Process  Execution  Language)  kann  durch  ent‐

sprechende technische Komponenten (Prozessmanager) eine Orchestrierung (Zusammenstellung in Pro‐

zessabläufen) der lose gekoppelten Dienste vorgenommen werden. 

 

  41Anhang 

 

Abbildung 18 ‐ SOA Szenario aus dem Fraunhofer FOKUS eGoverment Labor

Webservice­Technologie 

Die Webservice‐Technologie basiert  ausschließlich  auf offenen  Standards  (wie  XML, WSDL  und  SOAP) 

und  ist damit weitgehend unabhängig von Herstellern, Middleware‐Technologien  (wie  J2EE,  .NET etc.) 

und Programmiersprachen (wie Java, C#, C etc.). 

Fast alle aktuellen Programmiersprachen und Entwicklungsumgebungen besitzen mittlerweile Elemente, 

mit denen die Standards rund um XML, WSDL und Webservices unterstützt werden können. Durch den 

Einsatz  von  Service Registries und Repositories  können beliebige Anwendungen bzw. Dienste  in  Form 

von Webservices  im  Internet oder  in einem  Intranet angeboten, beschrieben und von anderen Anwen‐

dungen gefunden und genutzt werden. Fachlich modellierte Prozesse, die als Webservice implementiert 

und bereitgestellt wurden, zeichnen sich bei entsprechender funktionaler Granularität durch eine hohe 

Wiederverwendbarkeit aus und lassen sich somit wesentlich schneller und flexibler mit anderen Services 

zu  komplexen Dienstleistungen  verbinden  als  die  bisherigen  starren  Softwaresysteme.  Konzepte  zum 

verteilten Service Management zur Sicherstellung von Service Level Agreements (SLA) oder dem Vorge‐

hen bei Fehlersituationen berücksichtigen auch erforderliche betriebliche Aspekte. Verbunden mit den 

SOA‐Konzepten hat  sich die Webservice‐Technologie  zur bevorzugten  Lösung  in den Bereichen des E‐

Business und E‐Government entwickelt, die von allen Herstellern relevanter IT‐Infrastrukturen und Stan‐

dardanwendungen akzeptiert wurde. Auf der Basis  lose gekoppelter Systeme können die  Integrations‐

kosten zur Realisierung organisationsübergreifender Geschäftsprozesse deutlich gesenkt werden. 

 42  Anhang 

XÖV als Ansatz für semantische Interoperabilität in Deutschland 

XÖV (XML für die öffentliche Verwaltung) wurde und wird im Rahmen der Initiative Deutschland‐Online 

auf Basis der OSCI‐Aktivitäten (OSCI‐Transport) in mehreren Projekten entwickelt. Zurzeit existieren u. a. 

folgende  Standardisierungsprojekte:  XMeld  (Meldewesen),  XJustiz  (Elektronischer  Rechtsverkehr), 

XGewerbe  (Gewerbewesen)  im  DIN,  XPersonenstand  (Personenstandswesen),  XSozial  (Sozialwesen), 

XBau  (Bauantragsverfahren), XPlanung  (Stadt‐ und Regionalplanung). Weitere  Informationen über  lau‐

fende XÖV‐Projekte und Standards sind www.osci.de zu entnehmen. 

SAGA  als  grundlegendes  Framework  für  E­Government­Anwendungen  auf  der  Ebene  des 

Bundes 

Das vom Bundesministerium des Innern herausgegebene Dokument "Standards und Architekturen für E‐

Government‐Anwendungen  (SAGA)" bildet einen grundlegenden Katalog  relevanter  Standards  für den 

Aufbau  von  E‐Government‐Infrastrukturen.  Wenngleich  nur  für  die  Bundesverwaltung  verbindlich, 

kommt  dem  SAGA‐Dokument  ebenso wie  dem  Architekturkonzept  des  Bundes  auch  für  die  anderen 

Verwaltungsebenen  (Länder,  Kommunen)  sowie  für  die Wirtschaft  eine  bedeutende  Orientierungsdi‐

mension zu. SAGA liegt mittlerweile in der Version 4.0 vor. In der aktuellen Version wird stärker als bis‐

her auf Anforderungen an die Zusammenarbeit mit und zwischen anderen Verwaltungsebenen (EU, Land 

und Kommune) eingegangen. Außerdem werden Aspekte wie Konformität von Prozess‐ und Datenmo‐

dellen  konkreter  als  bisher  beschrieben. Neben  dem  SAGA‐Dokument  existieren  eine  Reihe weiterer 

Dokumente, in denen weiterführende Architektur‐, Aufbau‐ und Betriebskonzepte definiert werden (sie‐

he www.kbst.bund.de) 

  43Anhang 

 

Abbildung 19 ‐ Betrachtungsperspektiven im E‐Government (SAGA Viewpoints) 

RM­ODP als konzeptionelle Grundlage für die Betrachtung von IT­Architekturen 

Ein für den Aufbau prozessorientierter IT‐Infrastrukturen wesentliches Betrachtungsmodell ist das "Refe‐

rence Model of Open Distributed Processing (RM‐ODP)". Das (ebenfalls im SAGA‐Dokument grundlegend 

erläuterte) Modell ist eine ISO‐Norm für die (formale) Beschreibung von verteilten offenen Informations‐

systemen. 

RM‐ODP bildet ein  integriertes mehrdimensionales Betrachtungsmodell, auf dessen Grundlage das Zu‐

sammenspiel sämtlicher für eine prozessorientierte  IT‐Infrastruktur benötigten  informations‐ und kom‐

munikationstechnischen  Elemente,  einschließlich  aller  Anwendungen  (Fachverfahrenssoftware)  und 

anderer Teilsysteme, aus verschiedenen Blickwinkeln (Viewpoints) beschrieben werden kann. In RM‐ODP 

werden konkret fünf Viewpoints definiert: Unternehmens‐ und Informationsperspektive (Enterprise und 

Information Viewpoint), funktionale Perspektive (Computational Viewpoint) sowie Ingenieurs‐ und Tech‐

nologieperspektive (Engineering und Technology Viewpoint). Durch die verschiedenen Betrachtungsper‐

spektiven  kann  die  Komplexität  reduziert werden.  Zudem  steigt  die  Verständlichkeit  der  technischen 

Lösung im Sinne unterschiedlicher Akteursperspektiven. 

 44  Anhang 

Kurzüberblick IT­Systeme 

Zugangstechnologien 

Im Bereich des Zugangs zu einer  integrierten E‐Government‐Infrastruktur sind verschiedene Rollen (wie 

z. B. Bürger, Wirtschaft, Mitarbeiter, externe Verwaltungen) und verschiedene Technologien und Stan‐

dards zu berücksichtigen. Bisher konnten im Rahmen der Fraunhofer FOKUS E‐Government‐Labor Aktivi‐

täten folgende relevante Bereiche und Technologien identifiziert werden: 

Analoge Zugangswege  ‐ Mit dem Begriff "analoge Zugangswege" sollen diejenigen Zugangsmöglichkei‐

ten  zusammengefasst werden, mit denen Bürger/Unternehmer bereits bisher mit Verwaltungen  kom‐

munizieren  konnten. Darunter  fällt der persönliche Besuch  z. B.  in  einem Bürgeramt/Bürgerbüro, der 

Kontakt über das Telefon (mit der Perspektive Service D115), die Briefpost und per Fax. Im Zuge der Ein‐

führung von modernen Verwaltungsstrukturen  sollen die bestehenden Möglichkeiten nicht verschwin‐

den, sondern erhalten und verbessert werden. 

Internetportale für Bürger und Wirtschaft ‐ Der digitale Zugang zu Verwaltungsdiensten für Bürger und 

Wirtschaft kann durch moderne Portaltechnologien oder verschiedene andere Frontends realisiert wer‐

den. Aus  technologischer Sicht können dabei verschiedene Lösungen eingesetzt werden, die sich nicht 

ausschließen,  sondern  auch  parallel  angeboten  werden  können.  Dazu  gehören  Web‐Anwendungen, 

Formular‐basierte  Zugänge  über  XML‐unterstützende  Office‐Anwendungen  oder  intelligente  PDF‐

Formulare,  Formular  Management  Systeme  (FMS),  E‐Mail  Zugang,  Bürgerbriefkästen,  Multichannel‐

Portale  für verschiedene z. B. mobile und multimediale Endgeräte  sowie der Zugriff auf Daten  in dem 

Dokumentensafe eines Bürgerportals, usw. 

Mitarbeiterportal  ‐  Im Gegensatz zu einem  Internetportal für Bürger und Wirtschaft, welches über das 

Internet erreichbar  ist,  ist der Zugriff auf ein Mitarbeiterportal nur über gesicherte verwaltungsinterne 

Verbindungen möglich. Mitarbeiterportale ermöglichen den Zugriff auf alle benötigten Daten und Diens‐

te und realisieren  im Zusammenspiel mit anderen Architekturkomponenten  in der Regel auch Funktio‐

nen wie Zugangskontrolle, Personalisierung, Informationsaggregation und Single‐Sign‐On. 

Elektronische Service‐Schnittstellen ‐ Standardisierte elektronische Anfragen von anderen Verwaltungen 

(kommunale, Landes‐, Bundes‐ und europäische Ebene) oder Unternehmen werden in Zukunft zum Ver‐

waltungsalltag gehören. Wenn die elektronischen Anfragen von anderen Verwaltungen  im  Idealfall die 

gleichen, standardisierten Formen (z. B. auf Basis von XÖV‐Standards) aufweisen wie elektronische An‐

  45Anhang 

fragen innerhalb der eigenen Dienste‐Architektur, kann die Abarbeitung von externen Anfragen in jeder 

Verwaltung auf die gleiche Weise fast vollkommen transparent durchgeführt werden. 

Identity Management und Elektronische Signatur 

Identity Management bildet die Grundlage  für die personalisierte Nutzung elektronischer Dienste. Das 

verwaltungsweite oder verwaltungsübergreifende  Identitätsmanagement kann auf verschiedenen tech‐

nologischen  Grundlagen  und  mit  verschiedenen  Sicherheitsniveaus  aufgebaut  werden.  Wesentliche 

technische  Basissysteme  des  (föderierten)  Identitätsmanagements  sind  Verzeichnisdienste,  in  denen 

Benutzern oder Benutzergruppen differenzierte Zugriffrechte zugeordnet werden. Für rechtsverbindliche 

elektronische Transaktionen werden qualifizierte elektronische Signaturen auf der Basis von Public Key 

Infrastrukturen  (PKI)  benötigt.  In  einer  zeitgemäßen  E‐Government‐Architektur  sind  entsprechende 

technologische Komponenten die den Umgang mit elektronischen Signaturen und dem neuen elektroni‐

schen Personalausweis (ePA) ermöglichen, zwingend zu berücksichtigen. 

Komponenten für das Business­Prozess­Management (E­Government­Plattform) 

Ein wesentliches Element einer  SOA‐Infrastruktur bildet ein Prozess‐Management‐System. Diese Kom‐

ponente ermöglicht auf der Basis entsprechender standardisierter Prozessbeschreibungen die automati‐

sierte Steuerung komplexer Prozessabläufe auf der Basis einer  logischen und technischen Verknüpfung 

einzelner  technischer  Systeme und Dienste. Darüber  verfügen Business‐Prozess‐Management‐Systeme 

über Werkzeuge zur Überwachung der eigentlichen Prozessabläufe  ("Business Activity Monitoring").  In 

einem kontinuierlichen Optimierungsprozess können diese Ergebnisse zur Verbesserung einzelner Pro‐

zessabläufe  eingesetzt werden.  Für  den  Betrieb  einer  SOA‐basierten  E‐Government‐Infrastruktur  sind 

weitere Komponenten  im Bereich einer  sogenannten Prozess‐Middleware erforderlich, die  inzwischen 

jedoch  vielfach  integraler  Bestandteil  herstellerbezogener  Systemlösungen  für  das  Business‐

Prozessmanagement (BPM) sind. Dazu gehören u. a. Application‐Server, Verzeichnis‐ und Transformati‐

onsdienste, Adapter‐Lösungen für Anwendungen ohne entsprechende Service‐Schnittstellen, etc. 

Basiskomponenten und Dienste 

Basiskomponenten  und  Dienste  stellen  "elementare"  funktionale  Bausteine  einer  E‐Government‐

Infrastruktur dar, deren Funktionen (Dienste) in verschiedenen Geschäftsprozessen potenziell in gleicher 

Weise eingebunden bzw. als "Dienst" genutzt werden können. Zu den bisher identifizierten Basiskompo‐

nenten gehören u. a.: Formular Management System  (FMS), Virtuelle Poststelle  (VPS/OSCI), Deutsches 

Verwaltungs‐Dienste‐Verzeichnis  (DVDV),  Zahlungsverkehrsplattform  (ZVP)  sowie  generische  Dienste 

 46  Anhang 

anwendungsübergreifender  IT‐Systeme  (wie z. B. aus dem Bereich Dokumentenmanagement, den Sys‐

temen des Finanzmanagements oder einer Geodateninfrastruktur). 

Fachanwendungen 

Fachanwendungen sind Software‐Systeme zur Unterstützung spezieller Verwaltungsabläufe. Jede größe‐

re Verwaltung betreibt  in der Regel  in verschiedenen Fachbereichen/Ressorts mehrere Dutzend bis zu 

mehreren Hundert Fachanwendungen. Die Fachverfahren bilden, in Bezug auf nach wie vor überwiegend 

nach Aufgaben strukturierte Verwaltungen, den Kern  IT‐gestützter Verwaltungsprozesse. Aufgrund der 

historisch  gewachsenen  IT‐Strukturen und der  föderalen Unabhängigkeit  existieren bei den Behörden 

zahlreiche verschiedene Lösungen für Fachanwendungen, die mit unterschiedlichsten Technologien  im‐

plementiert wurden,  verschiedene  Betriebssysteme  nutzen  und  individuelle  Schnittstellen  aufweisen. 

Mit Blick auf die Anforderungen einer prozessorientierten Verwaltung sind die oft geschlossenen Fach‐

anwendungen in die Dienste‐Infrastruktur möglichst effizient zu integrieren. 

Fachunabhängige / ressortübergreifende Anwendungen 

Den  fachunabhängigen bzw.  ressortübergreifenden Anwendungen  können  alle  IT‐Systeme  zugeordnet 

werden, die nicht für die Bearbeitung einer speziellen Fachlichkeit einer Verwaltung bestimmt sind, son‐

dern für fach‐ bzw. ressortübergreifende Aufgaben eingesetzt werden. Dazu gehören Anwendungen wie 

z. B.: Dokumenten‐ und Wissensmanagement, Systeme für Beschaffung und Vergabe, Finanz‐ und Perso‐

nalverwaltung, Geographische Informationssysteme, etc. 

Sicherheits­Infrastrukturen 

Die Sicherheit von Daten und Anwendungen  ist  für alle Verwaltungen von höchster Bedeutung. Dabei 

geht es neben der Anwendung von (auch für den Bereich Identity Management relevanten) Sicherheits‐

konzepten wie Authentifizierung, Zugangskontrolle, Verschlüsselung und elektronischer Signatur um die 

Berücksichtigung weiterer (auch nichttechnischer) Anforderungen, wie sie im Grundschutzhandbuch des 

Bundesamtes für Sicherheit  in der Informationsgesellschaft (BSI) näher erläutert werden. Dazu gehören 

u. a. räumlicher Schutz gegen Feuer und unberechtigtes Eindringen, Umsetzung von Anforderungen an 

Datenschutz,  Daten‐  und  Systemsicherheit  sowie  Lösungen  für  elektronische  Archive,  etc.  

(Siehe auch http://www.bsi.de/literat/bsi_standard/standard_1002.pdf175) 

Entwicklungsumgebungen 

Bei der Umsetzung von modernen E‐Government‐Architekturen sind an vielen Stellen Entwicklungsarbei‐

ten notwendig. Viele der zuvor erwähnten Komponenten wie z. B. Application Server, insbesondere aber 

auch die E‐Government‐Plattformen, bieten zum Teil integrierte Entwicklungsumgebungen an, die auch 

  47Anhang 

den Aufbau von WebService Schnittstellen und SOA‐Architekturen unterstützen. Die Leistungsfähigkeit 

und Qualität der eingesetzten Entwicklungsumgebungen ist ein wichtiger Faktor für die erfolgreiche Um‐

setzung von E‐Government Vorhaben. 

Service­, System­ und Netz­Management 

Für die Administration einer verteilten E‐Government‐Infrastruktur sind integrierte Service‐, System‐ und 

Netz‐Management‐Komponenten  notwendig,  die  eine Überwachung  und  Kontrolle  aller  vorhandenen 

Komponenten ermöglichen. Ein  integriertes Service‐, System‐ und Netz‐Management sollte eine End to 

End Überwachung  aller Prozesse und  Einzelschritte bieten und  in  Sonderfällen  (wie  z. B. dem Ausfall 

einer Komponente) entsprechende Warnungen und Fehlerbehebungen ermöglichen. 

Rechenzentrums­Infrastrukturen 

Bei der Konzeption und dem Aufbau moderner  leistungsfähiger E‐Government‐Infrastrukturen  (Server, 

Datenbanken, moderne Storage Systeme, etc.) kommt den konkreten betrieblichen Fragestellungen eine 

herausragende Bedeutung zu. Dabei müssen u. a.  insbesondere die bestehenden und sich abzeichnen‐

den personellen, technischen und sicherheitstechnischen Rahmenbedingungen für die zu betreibenden 

Infrastrukturen berücksichtigt werden. 

Netz­Infrastruktur 

Eine Netz‐Infrastruktur mit  ausreichenden Bandbreiten  ist  eine wichtige Grundlage  für  eine moderne 

prozessorientierte  E‐Government‐Infrastruktur.  Zukünftig  von  steigender  Bedeutung  sind  neben  der 

Bandbreite, Servicequalität, Sicherheit und Verfügbarkeit von Netzen auch die Möglichkeiten der Kopp‐

lung von Netzen (Deutschland‐Online‐Infrastruktur) sowie die Möglichkeiten zur Verlagerung spezifischer 

Funktionalitäten in die Netzinfrastruktur (z. B. im Rahmen von Government‐Service‐Bus‐Konzepten). 

ISBN 978-3-8396-0136-5

9 783839 601365