Durch die Einführung einer Service-orientierten Architektur versprechen sich viele Unternehmen ein besseres Business-IT-Alignment, also die schnellere und bessere Angleichung zwischen Fach- und IT-Abteilung. Eine Möglichkeit dies zu erreichen, besteht darin Prozesse durchgängig zu modellieren. Dabei wird eine zusätzliche Modellebene zwischen fachlichem und ausführbarem Prozess eingeführt, das sogenannte Systemmodell. In dieser werden durch Abbildungen und Transformationen Beziehungen zwischen Fach- und IT-Prozess herstellt, wodurch sich Änderungen (auf beiden Ebenen) lückenlos nachvollziehen lassen. Anforderungen sind in der Regel fachlich getrieben und werden danach technisch umgesetzt. Da Fach- und IT-Abteilung unterschiedliche Anforderungen und Sichtweisen auf die Realisierung eines Prozesses besitzen, erfolgt auch die Modellierung mittels verschiedener Prozessmetamodelle und Werkzeuge, wodurch es zum sogenannten Business-IT-Gap kommt. Die unterschiedlichen Werkzeuge haben einen weiteren Nachteil: fachliche und technische Artefakte werden meist an unterschiedlichen Orten (anwendungseigene Datenbank/Repository, Dateisystem, usw.) gehalten. Dieser Umstand steht konträr zur Nachvollziehbarkeit bei Änderungen zwischen den Modellen. Um dem entgegenzuwirken, realisieren wir ein zentral logisches SOA-Repository, welches sowohl fachliche wie auch technische Objekte als auch deren Beziehungen zueinander speichert.
In dieser Diplomarbeit wird mittels eines Grundmetamodells das zuvor skizzierte Repository eingeführt und sukzessive um Ausbaustufen erweitert, um eine durchgängige Modellierung zu realisieren. Zweiter Schwerpunkt dieser Arbeit ist die Einführung und Entwicklung von Impact Analysen, mit Hilfe derer Änderungsszenarien einer SOA-Landschaft durchgespielt werden können, um so Aussagen und Entscheidungshilfen für die langfristige Entwicklung der SOA treffen zu können. Ein solches Szenario könnte z.B. das Abschalten eines Service sein. Durch die lose Kopplung einer SOA können davon viele weitere Services und Prozess betroffen sein. Um die Stabilität der SOA-Landschaft zu gewährleisten, ist es essentiell solche Abhängigkeiten vor der Abschaltung eines Service zu kennen.