EP2537126A2

EP2537126A2 - Verfahren, computerprogram-produkt sowie computerlesbares speichermedium zur generischen erstellung eines strukturbaums zur beschreibung eines it-verfahrens

Info

Publication number: EP2537126A2
Application number: EP11702941A
Authority: EP
Inventors: Klaus Bermuth
Original assignee: DB Systel GmbH
Current assignee: DB Systel GmbH
Priority date: 2010-02-15
Filing date: 2011-02-03
Publication date: 2012-12-26
Also published as: US20120317050A1; CA2789393A1; WO2011098231A9; DE102010007967A1; WO2011098231A2

Abstract

Die Erfindung betrifft ein Verfahren, ein Computerprogramm-Produkt sowie ein computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens mit kompletter Umgebung aus Clients, Servern, Middlewarekomponenten, Applikationen und Netzwerkkomponenten, die ein Endanwender zur Durchführung eines spezifischen IT-gestützten Geschäftsprozesses benötigt. Die Erfindung beruht auf der generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie eines IT-Verfahrens, mit dem es möglich ist, alle zur Gesamtbehandlung eines IT-Verfahrens erforderlichen Informationen in einer definierten Struktur zu sammeln und zu verwalten, so dass alle für das Management eines IT-Verfahrens relevanten Vorgänge aus einer Daten-Quelle schöpfen und automatisiert werden können. Durch die Schleifenfreiheit und die Eindeutigkeit der Elemente wird eine Strukturierung der in dem IT-Verfahren enthaltenen Information geschaffen, die eine automatisierte Verarbeitung ermöglicht. Jedem der in dem Strukturbaum verwendeten Elemente wird ein Metaelementtyp im Metamodell zugewiesen. Das Metamodell beschreibt, welche Elementtypen zulässig sind. Die Elementtypen umfassen alle gängigen generischen IT-Komponenten, wie Server, Middleware, Storage, etc. Weiterhin wird festgelegt, welche Attribute zu den Elementtypen zugelassen und/oder erforderlich sind und welche Relationen mit ihren zugehörigen Attributen zwischen den Elementen erlaubt sind. Die Schleifenfreiheit wird erreicht, indem als Metastruktur ein azyklisch gerichteter Graph verwendet wird.

Description

Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT- Verfahrens Die Erfindung betrifft ein Verfahren, ein Computerprogramm-Produkt sowie ein computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens mit kompletter Umgebung aus Clients, Servern, Middlewarekomponenten, Applikationen und Netzwerkkomponenten, die ein Endanwender zur Durchführung eines spezifischen IT- gestützten Geschäftsprozesses benötigt.

Ein IT-Verfahren ist die komplett installierte, verschaltete und ggf. aktivierte Umgebung, bestehend aus Clients, Servern, Middlewarekomponenten, Applikationen und Netzwerkkomponenten, die ein Endanwender zur Durchführung ei- nes spezifischen, IT gestützten Geschäftsprozesses benötigt.

In ihrer Gesamtheit wird durch die Erfindung eine Gesamtbehandlung eines IT- Verfahrens zur Verfügung gestellt. Diese betrifft

- die automatisierte Installation des IT-Verfahrens

- die unternehmensweite Architektursteuerung,

- den Abschluss oder die Veränderung von Leistungsvereinbarungen für IT-Verfahren/ITServices mit Endkunden,

die technische Installation eines IT-Verfahrens,

- das Reporting über die Verfügbarkeit eines IT-Verfahrens und seiner Elemente,

das serviceorientierte Monitoring und Incident-Management von IT- Verfahren inklusive der zielgruppengerechten Zuweisung von Störungsmeldungen an den Verursacher einer Störung,

die Definition und Dokumentation von objektspezifischen Überwa- chungsaufgaben im Zusammenhang eines IT-Verfahrens.

Beim Management von IT-Verfahren benötigt man in verschiedener Hinsicht mehr oder weniger detaillierte Informationen über das technische Zusammenspiel der Elemente.

Hierfür gibt es eine Reihe von Anwendungen, die den Nutzer bei der Beschaffung und Verwaltung solcher Informationen unterstützen. Obwohl die benötigten Zusammenhänge immer eine identische Umgebung beschreiben, werden diese verschiedenen Betrachtungswinkel im Stand der Technik getrennt voneinander modelliert.

Beispielsweise folgt die Beschreibung für die IT-Verfahrensinstallation der Rei- henfolge Wurzelknoten - IT-Verfahren - Server - Middleware - Applikation. Für ein IT-Verfahren werden zuerst die Server installiert. Dann wird auf diese Server die Middleware, z.B. ein JEE Applikationsserver installiert, und dann wird hierauf die eigentliche kundenspezifische Applikation installiert.

Im serviceorientierten Monitoring erfolgt die Beschreibung anders. Hier folgt man der Reihenfolge Wurzelknoten- IT-Verfahren - Applikation - Middleware - Server. In dieser Beschreibung drückt sich die Ende-zu-Ende-Sicht des Nutzers aus. Ein IT-Verfahren ist gestört, wenn die kundenspezifische Applikation gestört ist. Die Applikation kann nicht arbeiten, wenn die Middleware ein Problem hat. Und die Middleware kann nicht funktionieren, wenn der zugrundeliegende Server nicht funktioniert.

Beim Abschluss von Leistungsvereinbarungen/Leistungsverträgen mit dem Endkunden spielen feingranulare Zusammenhänge in und zwischen den IT- Verfahren eine untergeordnete Rolle. In dieser Sicht sind aber die zu erbringenden Leistungsmengen und auch Leistungsqualitäten relevant,

die sich auf den IT-Verfahrensbetrieb auswirken. Um diese korrekt planen zu können, benötigt man Informationen über den Aufbau des IT-Verfahrens und die für jedes Element erforderlichen Qualitäten, wie Leistungsmengen, Servicelevel, etc. So wurden bereits Common Data Model (CDM) genannte Informationsmodelle entwickelt, die versuchen, konsistente Definitionen für die zu verwaltenden IT- Komponenten, Business-Systeme und Prozesse zu liefern, wobei auch die Beziehungen zwischen den Elementen berücksichtigt werden (siehe z.B. IBM Redpaper„IBM Tivoli Common Data Model: Guide to Best Practices").

Ein CDM besteht im Wesentlichen aus Daten-Definitionen, die in einem logischen Modell organisiert und in vorgegebener Weise in einer Datenbank gespeichert werden. Dadurch können Ressourcen-Instanzen identifiziert werden sowie Informationen über die Instanzen und deren Beziehungen untereinander verwaltet werden.

Geschäfts- und Infrastrukturprozesse können auf Basis des CDM mit den IT- Systemen, die die Leistung liefern, in Beziehung gesetzt werden. Die Datensät- ze werden dabei z.B. in Gruppen zusammengefasst, die sich gliedern in physische Einheiten, Netzwerk, Administration, Storage, etc. Die Organisation erfolgt hierarchisch durch Objektklassen und deren Instanzen. Die Hierarchie startet bei einem Wurzelelement, welches die abstrakten Klassen enthält, aus denen sich die logischen und physischen Klassen ableiten. Unterklassen erben dabei die abstrakten Eigenschaften ihrer übergeordneten Eltern-Klassen. Die Instanzen der Klassen repräsentieren letztlich die Ressourcen. Den Instanzen werden Attribute zugewiesen, die für die zugehörige Klasse spezifiziert sind. Instanzen können weiterhin Beziehungen untereinander besitzen. Jede Beziehung zwi- sehen zwei Ressourcen-Instanzen gehorcht vorgegebenen Definitionen, je nach Art der Beziehung. Im Allgemeinen können zahlreiche verschiedene Beziehungen zwischen gleichen Klassen und deren Instanzen vorliegen.

Jeder Instanz, die in einem CDM repräsentiert wird, sind ein Name und ein Be- zeichner zugeordnet, wobei unter Verwendung von bestimmten Namensregeln jeder Instanz ein eindeutiger Name zugewiesen wird.

Nachteile eines solchen klassischen, datenbankorientierten Designs, liegen darin, dass pro Elementtyp ganz unterschiedliche Beschreibungsstrukturen vorliegen. Die Elementbeschreibungen müssen sehr detailliert sein, um aus einer ausgefeilten Einzelbeschreibung der Elemente heraus Managementverfahren, wie z.B. Installationsvorgänge unterstützen zu können.

Es ist zwingend erforderlich, auch solche Informationen, die sich implizit ergeben oder berechnet werden können bei der Modellierung mitzuerfassen. So müssen viele Detailangaben, wie z.B. die Standardfilesysteme von Middleware- komponenten modelliert werden, obwohl diese aus Sicht des IT-Verfahrens nicht modifiziert werden können müssen.

So kann z.B. ein technischer Servername durch die Verknüpfung folgender Informationen gebildet werden:

IT-Verfahrensname + Umgebungsname + Kennzeichen„im Cluster verwendet ja/nein" + laufende Nummer (gewonnen aus der Abspaltung des Präfixes„Ser- ver" des Labels des Elements„Server 471 1") + Netzbereich der public-I P-

Adresse (Kindelement des Servers) + Servertyp (Linux, Solaris, Windows). In CDM müsste in der Beschreibung diese Festlegung des Namens im Rahmen der technischen Beschreibung des IT-Verfahrens/Servers exakt erfolgen. Da hier auch Informationen von Kindelementen benötigt werden, kann der Name jedoch durch reine Vererbung wie in CDM nicht gewonnen werden. Ein weiteres Beispiel ist eine externe Bildungsregel mit der Festlegung, dass Apache-Webserver grundsätzlich in bestimmte Pfade eines Filesystems installiert werden, z.B. /var/app. Die Information ist ausschließlich Bestandteil der Installationsskripte des IT-Verfahrens. Sie würde in der feingranularen CDM- Modellierung ebenfalls komplett mitmodelliert, da das CDM-Verfahren nicht in der Lage ist, diese Information zu erkennen, obwohl sie bereits implizit vorliegt. Die CDM-Verfahren unterscheiden weiterhin nicht zwischen den Eleme- nen der IT-Verfahrenstechnik und den zugrunde liegenden Plattform- Elementen, die gewöhnlich unterschiedlichen Verantwortungsbereichen zuge- ordnet werden.

Die Pflege der Daten ist im Stand der Technik daher entsprechend aufwändig und fehleranfällig. Weiterhin ist durch die Art der Modellierung nicht ausgeschlossen, dass durch logische Fehlverknüpfungen zwischen Instanzen oder Klassen Endlosschleifen entstehen, die eine generische Auswertbarkeit der Strukturinformationen stark behindern.

Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie eines IT- Verfahrens bereitzustellen, mit dem es möglich ist, alle zur Gesamtbehandlung eines IT-Verfahrens erforderlichen Informationen in einer definierten Struktur zu sammeln und zu verwalten, so dass alle für das Management eines IT- Verfahrens relevanten Vorgänge aus einer Daten-Quelle schöpfen und automatisiert werden können. Das erfindungsgemäße Verfahren hat das Ziel, das Zusammentragen aller technischen Parameter von IT-Verfahren optimal so zu un- terstützen, dass die Basisinformationen für die kaufmännische Abwicklung des Bestellprozesses, die Installation des IT-Verfahrens, die Überwachung des bereitgestellten IT-Verfahrens und die Beplanung neuer Releasestände homogen aus einer einheitlichen Datenstruktur erfolgen können. Die Beschreibung eines IT-Verfahrens erfolgt erfindungsgemäß in einer vordefinierten Reihenfolge der- art, dass bereits erfasste Informationen erhalten bleiben. Falls technische Werte zur Beschreibung eines IT-Verfahrens aus anderen bereits erfassten Beschreibungswerten des IT-Verfahrens (innerhalb und außerhalb des Strukturbaumes) ermittelt oder errechnet werden können, so wird auf die Beschreibung dieses technischen Wertes erfindungsgemäß verzichtet. Die Ermittlung dieser Werte geht weit über die übliche Vererbung von Eigenschaften zwischen Eltern- und Kindelementen in Verfahren des Stands der Technik hinaus. Weiterhin soll eine Vorrichtung bereitgestellt werden, die ein Speichermedium umfasst, auf dem ein Programm gespeichert ist, das von einer Datenverarbeitungsanlage gelesen werden kann und die Datenverarbeitungsanlage in die Lage versetzt, alle zur Gesamtbehandlung eines IT-Verfahrens erforderlichen Informationen in einer definierten Struktur zu sammeln und zu verwalten, so dass alle für das Management eines IT-Verfahrens relevanten automatisierbaren Vorgänge von der Datenverarbeitungsanlage automatisiert durchgeführt werden.

Diese Aufgaben werden durch das erfindungsgemäße Verfahren gemäß Pa- tentanspruch 1 , ein maschinenlesbares Speichermedium gemäß Anspruch 15 und ein Computer-Programm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode gemäß Anspruch 16 gelöst.

Vorteilhafte Weiterbildungen der Erfindung sind Gegenstände der abhängigen Ansprüche 2 bis 14.

Zur Veranschaulichung der Erfindung sind in den Figuren 1 bis 28 die Zusammenhänge in Diagrammen dargestellt. Fig. 1 zeigt eine Darstellung der erlaubten Eltern-Kind-Beziehungen auf Basis eines azyklisch gerichteten Graphen. Das Elternelement Parent (1 ) besitzt 2 Kinder, nämlich Child 1 (2) und Child 2 (3). Child 2 (3) ist auch Kind von Child 1 (2). Es ist nicht zulässig, das Elternelement Parent (1 ) als Kind (oder auch Kindeskind) seines Kindelements Child 2 (3) anzulegen (5), da sonst eine Schleife entstünde.

Fig. 2 zeigt, wie bei Unique- und Non-Unique-Elementen die Namen eindeutig gebildet werden. Hierbei bedeutet„Label" den Eigennamen des Elements. Bei Non-Unique-Elementen (8, 9) wird der Gesamtname aus dem Eigennamen und den Namen der übergeordneten Elemente gebildet. Fig. 3 geht aus Figur 2 hervor und zeigt eine Darstellung einer Referenz (10) auf ein Element (9).

Fig. 4 zeigt eine Darstellung von Primär- und Sekundärrelationen. Bei Sekun- därrelationen (13), die von einem Eltern- zu einem Kindelement verweisen, muss das Kindelement bereits mit einer Primärrelation (16) zu einem anderen Elternelement angelegt sein, sonst ist eine Sekundärrelation nicht zulässig (14). Im Bild symbolisiert die dünne Linie eine Primärrelation (16), die dicke Linie die Sekundärrelation (13).

Fig. 5 zeigt eine Darstellung von Detaillierungen im Strukturbaum eines IT- Verfahrens (17) am Beispiel der IP-Adressen (19, 21 , 24, 28) und IP- Dienste/IP-Ports (20, 22, 25, 26, 29). Fig. 6 zeigt die Modellierung einer Datenverbindung durch eine Sekundärrelation (13). Die Sender-Instanz (30) sendet Daten an die IP-Adresse 172.12.13.15 (38), Port 80 (39) der Empfänger-Instanz (37). Die Datenverbindung ist als Sekundärrelation (13) beschrieben, da nur ein existierender Ziel-Port auch angesprochen werden kann und dieser Port nur dann existiert, wenn auch die Emp- fänger-lnstanz existiert.

Fig. 7 ist abgeleitet aus Figur 6 und zeigt die Benennung einer Datenverbindung mittels eines eigenen Elements (42). Dies wird z.B. benötigt, um Datenverbindungen mit DNS-Namensauflösung zu beschreiben.

Fig. 8 ist abgeleitet aus Figur 7 und zeigt mehrere Sender (43, 48), die über eine DNS-Verbindung (42) an mehrere Empfänger (53, 58) senden. Die benannte Datenverbindung ist hierfür mehreren Elternobjekten (36) zugeordnet, die als Datensender innerhalb unterschiedlicher Sender-Instanzen (43, 48) gruppiert wurden. Der DNS-Dienst selbst ist hier nicht dargestellt.

Fig. 9 zeigt die Modellierung von Netzwerkdiensten, die eine Datenverbindung beeinflussen. Die hier beispielhaft gezeigten Datendienste einer Firewallregel (64) und einer Loadbalancing-Regel (66) sind als Kindelemente einer benann- ten Datenverbindung (42) angelegt und über Sekundärrelationen (13) mit den Elementen der zugehörigen physischen Komponenten (63, 65) verknüpft. Fig. 10 zeigt, wie Gruppierungselemente eingefügt werden. Die Gruppierungselemente für die beiden IT-Verfahrensgruppen (68, 74), die zwei Releases (70, 71 ) des IT-Verfahrens 1 (69) sowie die beiden zum Release 1 .1 (70) gehören- den Installationsstränge A (72) und B (73) sind hier sechseckig dargestellt.

Fig. 1 1 zeigt die Darstellung eines IT-Verfahrens (77) mit zwei Releases (78, 79), bei denen jeweils die Middleware-Instanzen (81 , 82) unterschiedlich gestaltet wurden. Ein Apache (82) wird auf einem Server (80) installiert, der in Re- lease 1 (78) und Release 2 (79) verwendet wird. Im Release 2 (79) wird jedoch der Apache 2 (81 ) als ein weiterer Apache auf diesem Server installiert. Wird der Server (80), wie in Figur 1 1 dargestellt, unique modelliert, ist nicht, bzw. nur über Zusatzrelationen zwischen der Middleware-Instanz und dem Release oder über Attribute darstellbar, dass Apache 2 (81 ) nur zum Release 2 (79) ge- hört.

Fig. 12 zeigt die erfindungsgemäße Kombinationslösung des in der Beschreibung zur Figur 1 1 dargelegten Problems. Auf der linken Seite wird der Server in den beiden Releases non-unique modelliert (83, 84), um so den IT- Verfahrenszusammenhang darzustellen. Er wird dann mit dem unique modellierten physischen Server (89), der unternehmensweit einmalig ist, im Plattformbaum (88) per Sekundärrelation (13) verknüpft.

Fig. 13 stellt in einem Diagramm dar, wie beim Durchlaufen der Prozessschritte zur Bereitstellung eines IT-Verfahrens die benötigten Informationen zur vollständigen Installation des IT-Verfahrens sukzessive bereitgestellt werden. Links ist jeweils die zu beschreibende Information aufgeführt, oben der jeweilige Informationsgeber. Schraffierte Bereiche signalisieren fehlende Informationen, in schwarzen Bereichen ist die Information vollständig.

Fig. 14 zeigt, wie durch einen Value-Source-Mechanismus bei der Erfassung von neuen Elementen die Auswahlmöglichkeiten für Namen und/oder Attribute auf Basis der bereits im Strukturbaum oberhalb des Elements vorhandenen Informationen eingeschränkt werden. Fig. 15 zeigt, welche Unterschiede beim Vergleich zweier beispielhafter Releases (78, 79) erfasst werden. Veränderungen sind jeweils fett dargestellt, so der Rückbau der Gruppe INet (99) mit den Eltern und Kindrelationen (98), das Hinzufügen des Elements Apache Webserver2 (87) mit der Relation (100) und die Änderung des Attributs Typ von„Solaris9" auf „Solarisl O" im Element Serverl (96, 97).

Figur 16 zeigt beispielhaft, wie Teilstrukturbäume exportiert werden. Der Teilstrukturbaum der dargestellten Sender-Instanz (30) wird bis zu seinem End- Element„Benannte Datenverbindung" (42) erfasst und dann über eine Sekundärrelation mit der Empfängerinstanz (I P-Port, 39) verknüpft. Innerhalb der Definition der Meta-Relation zu Relation (1 3) wird einmalig für alle diese speziellen Metarelationen festgelegt, dass der Export des Baumes vom Kindelement (hier I P-Port ,39) aus die baumaufwärtsgerichtete Spiegelung enthält. Deshalb wird auch der baumaufwärts gerichtete Teilstrukturbaum bis zur Empfänger- Instanz (37) und zur ROOT (67) mit exportiert. Nun enthält der Export alle notwendigen Informationen um die Datenverbindung zu modellieren. Die ohne diesen aufwärtsgerichteten Export fehlenden Informationen der Ziel-IP-Adresse (38) und der Empfänger-Instanz (37) stehen nun in dem Export zur Verfügung.

Figur 17 zeigt, wie sowohl die IT-Verfahrensinstallation als auch das Monitoring des IT-Verfahrens auf den gleichen Datensatz zugreifen, dabei aber unterschiedliche Strukturbäume darstellen. Gegenüber der Darstellung für die IT- Verfahrensinstallation (links) ist die Darstellung des Strukturbaums für das Mo- nitoring (rechts) invertiert (man beachte die Positionierung der Elemente 18 und 101 ). In beiden Bäumen können zusätzliche Gruppierungselemente enthalten sein, die für die Konvertierung nicht relevant sind, und ggf. auf anderem Wege zugefügt werden müssen (Elemente 78 und 102). Figur 18 zeigt beispielhaft, wie ein Cluster vom Typ a (z.B. Veritas) dargestellt wird. Veritas wird hier auf 2 Servern ( 107, 108) installiert und stellt dann eine eigenständige Betriebssysteminstanz (1 04) für die Verfahren bereit. Diese Betriebssysteminstanz wird dann ganz normal von den Verfahren genutzt, d.h. es wird eine Verfahrensinstallationsbasis (105) (Filesysteme mit Gruppen und Rechten) aufgesetzt, in die dann die Middleware- (106) und Applikationskomponenten (nicht dargestellt) installiert werden. Die Server können sowohl logi- sehe, als auch virtuelle Server sein. Die Server müssen bereits aufgesetzt sein, bevor Veritas installiert wird. Deshalb erfolgt die Anbindung jeweils über eine Sekundärrelation (13). Die Figur 1 9 zeigt die beispielhafte Darstellung eines Clusters vom Typ b. Der Datensender (Sender-Instanzl , 43 und analog Sender-Instanz2 48) spricht eine DNS-Farmadresse (109) an. Der DNS-Loadbalancing-Dienst (hier nicht dargestellt - das netzwerktechnische Gerät, in dem die DNS-Adresse 109 aufgelöst wird) gibt wahlweise die IP-Adresse 172.12.13.14 (54) oder 172.12.1 3.1 5 (59) als Ziel zurück. Damit werden abwechselnd die Empfänger-Instanzen 1 (53) und 2 (58) angesprochen.

Die Figur 20 zeigt, wie die Beispielcluster aus den Figuren 19 und 20 auf den Monitoring-Strukturbaum abgebildet werden. In den 3 Beschreibungsvarianten für Cluster (Betriebssystemcluster, Globales und Lokales Loadbalancing), werden die Elemente (104), (1 10) , (1 1 1 ) für das Monitoring übersetzt in das Elternelement„Cluster" (1 14). Die Instanzen zu diesen Clusterelementen (1 1 5)/(1 16) sind dann die Elemente (107)/(108), bzw. (53)/(58). Während beim Betriebssystemcluster diese Information aus dem Installations-Strukturbaum sofort ab- leitbar ist, muss bei den beiden anderen Loadbalancingtypen diese Information durch Auswertung der Datenverbindungen (109) bzw. (36) indirekt ermittelt werden.

Die Figur 21 zeigt die Modellierung einer elementspezifischen Überwachung am Beispiel eines Webservers (1 1 7).

Die Figur 22 zeigt beispielhaft, wie die jeweiligen Applikationsteile (101 ) eines IT-Verfahrens den Geschäftsprozessen (102) eines Anwenders zugeordnet werden können, die dann mit End-to-End-Monitoringwerkzeugen (123) überwacht werden können.

Die Figur 23 zeigt, wie mithilfe des Teilstrukturbaums„IT-Verfahren" (77) das IT-Verfahren u.a. mit den benötigten Mengen und Qualitäten der Server (124, 126, 129) beplant wird. Über den Teilbaum "IT-Plattform" (88) erfolgt die Zu- Weisung zu den exakten physischen Instanzen (133, 134). Die Figur 24 zeigt ein einfaches IT-Verfahren, das auf einem virtuellen Server (KVA1 -206v, 138) zwei Middleware-Komponten bereitstellt (Apache 140 und JBOSS 141 ), die miteinander verknüpft (148) sind. Der virtuelle Server ist über eine Sekundärrelation (13) einem physischen Server (RZ1 -471 1 .linux, 154) zu- gewiesen.

Die Figur 25 zeigt das IT-Verfahren aus Figur 24, das um die Datenbank Oracle DB-KVA1 (161 ) erweitert wurde. Weiterhin ist die Endgerätegruppe (159), d.h. der Nutzer des IT-Verfahrens, als Client vom Typ OSS-Endgerätegruppe dargestellt. Die Sekundärrelationen (13) zeigen hier die Datenverbindungen vom Endgerät (159) zum Webserver (140), vom Webserver (140) zum Applikationsserver JBOSS (141 ), vom Applikationsserver (141 ) zur Datenbank (161 ). Die Figur 26 zeigt, wie zwei verschiedene Clientgruppen (Internet 159, Extranet 165) über die DNS-Adresse www.kva1 .com (233) auf eine Webserver-Farm (140) zugreifen. Das Loadbalancing wird durch den DNS-Dienst gesteuert. Die hierfür notwendigen Parameter (z.B. Loadbalancingverfahren round-robin, ...) sind als Attribute in der DNS-Datenverbindung (233) hinterlegt. Der DNS-Name wird durch das IT-Verfahren verantwortet und ist weltweit eindeutig. Daher ist der DNS-Name unique modelliert und primäres Kind der IT- Verfahrensumgebung (137). Die Datenverbindungen (147) nutzen diesen Namen über Sekundärrelationen (13), hier die Relationen zwischen den Elementen (147) und (233).

Die Figur 27 zeigt die Verwendung der Informationen des Strukturbaums in mehreren Zielsystemen. Aus dem links dargestellten Strukturbaum der IT- Verfahrensbeschreibung werden mithilfe von Analyseregeln (172 bis 178) Daten bereitgestellt für die Angebotsdefinition (172), die Assetdefinition (173), die Qualitätssicherung (174), die Ermittlung, Reihung und Parametrisierung der Installationsaufgaben (175), das objektspezifische Monitoring (176), das serviceorientierte Monitoring (177) und die IT-Governance (178). Die Daten werden entsprechend aufbereitet (hier dargestellt bei 179, 181 , 182, 184, ggf. auch weiteren Fällen) und den geeigneten Datennutzern (186, 187, 180, 188, 189, 190, 191 , 183, 192, 185) zur Verfügung gestellt. Die Figur 28 stellt dar, wie verschiedene Werkzeuge zusammenwirken, um eine Gesamtbehandlung eines IT-Verfahrens auf Basis des Strukturbaumes zu ermöglichen. Links sind die Zuliefersysteme (193) und die Elemente der Qualitätssicherung (1 94) genannt. Der Strukturbaum selbst wird in verschiedenen Mandanten (195) gehalten, die Basis für den Erfassungsprozess bzw. den In- stallationsprozess sind. Die kreisrunden Elemente (21 9 bis 223) bezeichnen jeweils eine Analysekomponente des Strukturbaums. Ganz rechts sind die Zielsysteme bzw. Nutzer (196) dargestellt, die die Informationen aus dem Strukturbaum verarbeiten.

In Figur 29 ist beispielhaft dargestellt, wie eine Vorlage für eine technische IT- Verfahrensbeschreibung aussehen kann (links) und wie sie verwendet wird, um ein IT-Verfahren zu modellieren (rechts). Die Vorlage für die hier verwendete Konfiguration eines Apache-Webservers auf einem Linux-Server (236, mit zu- gehörigen Kindelementen 237 bis 242, 139, 147) umfasst die Basisdarstellungen aller aus der IT-Verfahrenssicht benötigten Elemente, beginnend beim Linux-Server (237), über die IT-Verfahrensinstallationsbasis (139) (Filesysteme, Gruppen, Rechte) bis zur Middleware Apache (239) und allen datentechnischen Konnektivitäten (238, 240, 241 , 242, 147). Soweit möglich und sinnvoll, sind die Attribute zu den einzelnen Elementen mit Werten vorbelegt, z.B. mit den aktuellen Versionsnummern des Linux-Betriebssystems und des Apache-Webservers. Im zu modellierenden IT-Verfahren kann die Vorlage für jeden der beiden Apache-Webserver (246, 252) verwendet werden.

Die Vorlage wird jeweils mittels des Smart Copy-Mechanismus (243) in die IT- Verfahrensbeschreibung unter die IT-Verfahrensumgebung Produktion (245) übertragen.

Hierbei werden die vorgegebene Struktur dupliziert und die Eigennamen und Attribute der Elemente angepasst.

Bei dem Kopiervorgang werden einige der Vorgabewerte manuell ersetzt, z.B. wird die I P-Adresse 1 72.a.b.c (240) aus der Basisdarstellung des Apache- Servers (239) in der Vorlage nach dem Smartcopy-Vorgang in der Beschreibung des Apachel (140) im IT-Verfahren ersetzt durch 172.17.75.87 (249). Ebenso können im Rahmen des Kopiervorgangs auch Attribute verändert werden. Figur 30 zeigt, wie eine Referenzarchitektur (260, mit zugeordneten Kindelementen) Leistungselemente eines Servicekatalogs (235, mit zugeordneten Kindelementen) und technische Lösungen (254, mit zugeordneten Kindelementen) als Beschreibungsgrundlage verwendet. Die Referenzarchitektur (260, mit zugeordneten Kindelementen) steht dann als eigenständige Kopiervorlage für die rechts dargestellte Modellierung einer IT-Verfahrensbeschreibung zur Verfügung. Links oben ist die aus Figur 29 bekannte Vorlage für die Konfiguration eines Apache-Webservers auf einem Linux-Server dargestellt. Links unten ist eine Vorlage aus dem Bereich der technischen Lösungen dargestellt, bei der ein Informationsserver (258) auf einem OSS-Windows-Server (256) angelegt ist. Auf dem Informationsserver (258) sind als Anwendung ein Dokumentationssystem (259) und alle datentechnische Konnektivitäten (240, 241 , 242, 147) angelegt.

Die Leistungselemente aus dem Servicekatalog für den Apache-Server auf Li- nux (236 mit zugehörigen Kindelementen) werden zusammen mit den Elementen des Informationsservers aus dem Bereich der technischen Lösungen (255 mit zugehörigen Kindelementen) in einer Referenzarchitektur (261 mit zugehörigen Kindelementen) zusammengeführt.

Bei der auf der rechten Seite dargestellten Modellierung des IT-Verfahrens können sowohl die Referenzarchitektur als auch weitere, einzelne Elemente aus dem Servicekatalog bzw. aus den technischen Lösungen verwendet werden. Allgemein wäre jede beliebige Kombination aus Referenzarchitekturen , Leistungselementen aus dem Servicekatalog, technischen Lösungen und sonstigen Elementen (z.B. 253 und 272) denkbar. So sind in der in Figur 30 rechts dargestellten Modellierung des IT-Verfahrens mithilfe des Smart-Copy- Verfahrens (243) sowohl die zuvor beschriebene Referenzarchitektur (261 , mit zugehörigen Kindelementen) als auch ein weiterer Apache auf Linux (Apache- auf-Linux-2, 252 mit zugehörigen Kindelementen) eingefügt worden; darüber hinaus wurden noch als sonstige Elemente ein OSS_Server-virtuell; z/OS Host (253) und das Spez-Doku-System (272) angelegt.

Die Erfindung basiert auf einer geeigneten Modellierung des IT-Verfahrens, aus der sich alle für das IT-Verfahren relevanten Informationen darstellen und automatisiert verarbeiten lassen. Hierzu ist es erforderlich, dass die Informationen selbstkonsistent und eindeutig modelliert werden. Weiterhin muss ausgeschlossen werden, dass bei einer automatischen Verarbeitung der Informationen versteckte Schleifen auftreten können. Da die Modellierung bereits im Vorfeld der Realisierung des IT-Verfahrens zur Verfügung stehen soll, erfolgt die Modellie- rung generisch. Dies hat weiterhin den Vorteil, dass auch Veränderungen in der IT-Verfahrenstopologie behandelt werden können, ohne konkrete Realisierungen der Elemente abwarten zu müssen.

Das erfindungsgemäße Verfahren nach Anspruch 1 stellt ein Verfahren zur ge- nerischen Erstellung eines Strukturbaums zur Beschreibung der Topologie eines IT-Verfahrens zur Verfügung. Hierbei wird die komplette Umgebung aus Clients, Servern, Middlewarekomponenten, Applikationen und Netzwerkkomponenten, die ein Endanwender zur Durchführung eines spezifischen IT- gestützten Geschäftsprozesses benötigt, modelliert. Dabei entsprechen die Elemente des Metamodells den Komponenten des IT-Verfahrens.

Jedem der in dem Strukturbaum verwendeten Elemente wird ein Metaelement- typ im Metamodell zugewiesen. Das Metamodell beschreibt, welche Elementtypen zulässig sind. Die Elementtypen umfassen alle gängigen generischen IT- Komponenten, wie Server, Middleware, Storage, etc. Weiterhin wird festgelegt, welche Attribute zu den Elementtypen zugelassen und/oder erforderlich sind und welche Relationen mit ihren zugehörigen Attributen zwischen den Elementen erlaubt sind.

Um bereits bei der Modellierung zu gewährleisten, dass keine unerwünschten Schleifenbeziehungen unter den Elementen auftreten können, werden vom Formalismus der Metastruktur nur eindeutige und schleifenfreie topologische Beziehungen zwischen den IT-Verfahrenselementen erlaubt. Die Schleifenfreiheit wird erreicht, indem als Metastruktur ein azyklisch gerichteter Graph verwendet wird. Ein azyklisch gerichteter Graph startet bei einem Wurzelelement, unter das sich alle Elemente in Eltern-Kind-Beziehungen (4) einordnen. Kindelelemente (2, 3) ordnen sich dabei unter ihre jeweiligen Elternelemente (1 ). Die Kindelemente dürfen wiederum selbst Elternelemente (2) von weiteren Kindelementen (3) sein, allerdings mit der Einschränkung, dass sie keine Kindelemente haben dürfen, die ihrerseits zu ihren eigenen Elternelementen zählen (5, s. Figur 1 ). Da schon beim Anlegen der Elemente durch den Formalismus der Metastruktur verhindert wird, dass einem Elternelement Kindelemente zugeord- net werden können, die ihrerseits bereits als deren Elternelement angelegt sind, können unerwünschte Schleifen erst gar nicht entstehen.

Durch das erfindungsgemäße Verfahren ist weiterhin sichergestellt, dass ein Kindelement nur je eine Relation mit seinem/seinen Elternelement(en) hat. Man kann bei einer bestehenden Relation zwischen Elternelement und Kindelement keine zweite Relation zwischen denselben Elementen anlegen.

Durch diese Einschränkung wird beispielsweise verhindert, dass in ein Server- Cluster zweimal der gleiche Server hinzugefügt wird.

Durch die Schleifenfreiheit und die Eindeutigkeit der Elemente wird eine Struk- turierung der in dem IT-Verfahren enthaltenen Information geschaffen, die eine automatisierte Verarbeitung der Information ermöglicht.

Jedes der im Strukturbaum enthaltenen Elemente kann mit Attributen konkretisiert werden.

Zweckmäßiger Weise werden dabei 4 Kategorien von Attributen unterschieden:

1 . Attribute, die für die Zusammenhangsbeschreibung im Rahmen der Installation wichtig sind:

Wenn beispielsweise eine Betriebssysteminstanz installiert werden soll, muss bekannt sein, welches Betriebssystem in welcher Version zu installieren ist. Wenn Datenverbindungen aufgebaut werden, müssen die IP- Adressen und die angesprochenen Dienste bekannt sein.

2. Attribute, die für die Betriebsorganisation wichtig sind:

Es muss z.B. bekannt sein, mit welchem Servicelevel das Element betrieben wird und wer bei technischen und fachlichen Fehlern für den

Support verantwortlich ist.

3. Attribute für die Abrechnung der Leistung: Leistungen werden erbracht.

Es müssen der Besteller und die Vertragskonditionen bekannt sein. Einige dieser Punkte sind auch betriebsrelevant. Deshalb ist es sinnvoll, diese Informationen mit Punkt 2 direkt zu verknüpfen.

4. Attribute für das technische Finetuning der Komponenten:

Geeignete Parameter für das Finetuning von Komponenten sind von vielen, teils auch fachlichen Parametern abhängig. Diese Detailkenntnisse sind für eine initiale Installation eines IT-Verfahrens unerheblich. Bei- spielsweise lässt sich eine Datenbank für ein IT-Verfahren über einfache Kommandos wie CREATE TABLE, INSERT, ... aufbauen. Die 500 Spezi- alparameter zur Konfiguration der Datenbank sind dabei während der Erstinstallation unerheblich.

Die in einem Strukturbaum eines IT-Verfahrens enthaltenen Informationen wer- den zur Gesamtbehandlung eines IT-Verfahrens weiterverarbeitet. Der erfasste Strukturbaum lässt sich in vielfältiger Weise nutzen. Dabei werden immer wieder ähnliche Schritte durchlaufen, die in speziellen Komponenten zusammenge- fasst werden können.

Zu unterscheiden sind dabei generell die 4 Schritte:

1. IT-Verfahrensbeschreibung (in Baumdarstellung oder graphisch als ge- nerisch erzeugtes Architekturbild visualisiert)

2. Analyse des Strukturbaums als Vorstufe für die Datenbereitstellung für die Zielsysteme

3. Datenaufbereitung, Anpassung der Daten auf die jeweiligen Schnittstel- len der Zielsysteme

4. Nutzung der Daten durch die Zielsysteme

Einen Überblick über die Zielsysteme liefert Figur 27.

Bereits bei der Erfassung der Informationen können die in Grundstrukturen bzw. Vorlagen enthaltenen Informationen des Strukturbaums (170) weiterverarbeitet werden. Die kaufmännischen Zielsysteme (186, 187) verwenden die Informationen mittels eines Konverters (179) in der Angebotsphase. Die in einem Strukturbaum modellierten Elemente werden mit Artikelnummern und Preisen versehen. Das Angebotsmanagement kann bis zum Vertragsabschluss gesteu- ert werden.

Während der Systemplanung werden die Informationen vom Asset-Management und vom Kapazitätsmanagement (180) verwendet. Dies unterstützt beispielsweise die Zuweisung von Servern oder Storage im IT-Verfahren. Das Assetma- nagement ist die Anlagenverwaltung eines IT-Verfahrens. Dort ist jedem Element seine eindeutige ID zugewiesen. Zusätzlich werden hier Kontaktinformationen zu den Kunden, Vertrags-IDs, und ähnliches verwaltet. Außerdem baut sich auf dem Assetmanagement das Kapazitätsmanagement auf, in dem die insgesamt vorhandenen und die belegten bzw. noch freien Ressourcen men- genmäßig verwaltet werden. Das Assetmanagement verwendet aus dem Struk- turbaum (170) Informationen darüber, wie viele Ressourcen belegt werden sollen.

Im Rahmen der Qualitätssicherung können komplexe Prüfroutinen (181 ) auf die aufbereiteten Daten (174) zugreifen, um komplexere Prüfungen durchzuführen, die über die bisher im Strukturbaum (170) erfassten Zusammenhänge hinausgehen.

Für die Installation des IT-Verfahrens wird auf die im Strukturbaum (170) ent- haltenen Informationen zugegriffen, um die Installationsaufgaben zu ermitteln, sie in eine passende Reihenfolge zu bringen (182) und geeignet zu parametri- sieren (175).

Die eigentliche Installation kann durch eine Workflowkomponente (182) über- wacht werden. Die einzelnen Installationsaufgaben werden entweder automatisch durch geeignete Skripte (189) durchgeführt, oder es werden Arbeitsaufgaben in das Changemanagement (190) eingestellt, die dann manuell von den zuständigen Betriebsführern durchzuführen sind. Der Installationsstatus wird an das Assetmanagement (191 ) und das Kapazitätsmanagement übermittelt.

Nachdem die Anwendung installiert ist, sollte sie auch überwacht werden. Hierfür können einerseits im Baum erfasste IT-verfahrensspezifische Monitoringaufgaben in den individuellen Monitoringsystemen (183) beauftragt werden. Andererseits kann der Strukturbaum, wie in Anspruch 12 beschrieben, maschi- nell gewendet werden (184) und dann dem serviceorientierten Monitoringsystem (192) zugeführt werden. Beide Tasks erfordern ebenfalls eine Interpretation der Informationen aus dem Strukturbaum (170), um die Monitoringsysteme einzurichten bzw. zu konfigurieren. Weiterhin können Auszüge aus den im Strukturbaum (170) erfassten Informationen an das Enterprise Architektur Management (185) übergeben werden. Die Informationen unterstützen die Planung beispielsweise, indem für jedes IT- Verfahren / jede Umgebung jeweils für alle Elemente die aktuell verwendeten Versionsnummern bekannt sind, oder indem alle technischen Datenbeziehun- gen zwischen verschiedenen IT-Verfahren bereitgestellt werden können. Dies unterstützt den Abgleich gegen fachlich bekannte Datenbeziehungen zwischen den IT-Verfahren.

Anspruch 2 beschreibt eine vorteilhafte Ausgestaltung des Anspruchs 1 . Die Eindeutigkeit der Namensgebung für die Elemente der generischen Metastruktur wird mithilfe von Unique- und Non-Unique-Elementen geregelt.

Die Entscheidung, ob ein Element unique oder non-unique ist, wird im Metamo- dell getroffen. Unique-Elemente (6, 7) sind solche, deren Eigenname (im allge- meinen bestehend aus Elementtyp und Elementname) im Rahmen der Topolo- gie genau einmal vorkommt. Non-Unique-Elemente (8, 9) erhalten dagegen ihren in der Topologie eindeutigen Namen erst dadurch, dass bei der Generierung des Elements ihr Eigenname mit dem Namen des übergeordneten Elternelements zu einem Gesamtnamen verknüpft wird (s. Figur 2). Der Eigenname von Non-Unique-Elementen muss daher nicht eindeutig bezeichnet werden.

Weiterhin sind in der Metastruktur nur zwei Arten von Beziehungen zwischen Eltern- und Kindelementen erlaubt. Beim Anlegen der Elemente wird entschieden, ob es sich bei der Eltern-Kind-Beziehung um eine Primärrelation (16) oder um eine Sekundärrelation (13) handelt. Wenn also ein Kindelement (15a, 15b) neu in das Metamodell des IT-Verfahrens aufgenommen wird, muss es mindestens einem Elternelement (12) über eine Primärrelation (16) zugewiesen werden. Erst dann kann das Kindelement (15b) auch noch weiteren Elternelementen (1 1 ) über Sekundärrelationen (13) zugewiesen werden. Das bedeutet, dass Sekundärrelationen nur zu bereits im Metamodell angelegten Elementen führen dürfen (s. Figur 4) . Besitzt also ein Kindelement (15a) keine Primärrelation, ist es nicht möglich, ihm eine Sekundärrelation (14) zuzuweisen.

Der Gesamtname für die Non-Unique-Elemente der Plattformgruppe wird über ihren Eigennamen in Verbindung mit dem Elternelement durch eine den Namen definierende Primärrelation gebildet. Da der Gesamtname des Non-Unique- Elements eindeutig sein muss, können Non-Unique Elemente niemals mehr als eine Primärrelation zu einem Elternelement besitzen. Entsprechend verhindert der Formalismus der Metastruktur erfindungsgemäß die Zuweisung von mehr als einer Primärrelation an ein Non-Unique-Kindelement.

Beim Einfügen einer neuen Sekundärrelation auf ein bereits bestehendes Ele- ment wird ein direkter Verweis auf das bestehende Element erstellt. Die Anfangs- und Endpunkte aller Relationen werden aus den Namen von Eltern- und Kindelementen der Relation definiert.

Als weitere Einschränkung in der Metastruktur wird zwischen zwei Elementtypen jeweils nur entweder eine Primärrelation oder eine Sekundärrelation er- laubt. Die Primärrelation drückt aus, dass ein Kindelement nur auf Basis des Elternelements existieren kann. Hingegen drückt die Sekundärrelation aus, dass das Elternelement ein bereits bestehendes Kindelement nutzt. Erzeugung und Nutzung in einem schließen sich aus. Somit wird durch diese Einschränkung eine sprachliche und inhaltliche Präzisierung geschaffen, die der späteren Nutzung des Strukturbaums für Automationszwecke zugute kommt.

Da zu jedem im Strukturbaum enthaltenen Element Attribute zugewiesen werden können, können die für das Zusammenspiel der Elemente relevanten Eigenschaften der Elemente erfasst werden.

Das Gleiche gilt für die im Strukturbaum enthaltenen Relationen, für die mit Hil- fe von Attributen ebenfalls die für das Zusammenspiel der Elemente relevanten Eigenschaften der Relationen erfasst werden können.

In Anspruch 3 ist beschrieben, wie vorteilhaft in dem Metamodell Datenverbindungen modelliert werden.

Datenverbindungen beschreiben den Datenaustausch zwischen Sender und Empfänger, z.B. auf Basis einer IP-Verbindung. Der Sender kann Daten an einen Empfänger nur dann versenden, wenn der Empfänger existiert und empfangsbereit ist. Die Datenverbindung wird daher als Sekundärrelation (13) modelliert (s. Figur 6).

In einigen Fällen besteht ein Bedarf, Datenverbindungen identifizierbar zu machen. Dies geschieht, in dem die Datenverbindung als eigenes Element modelliert wird, die über einen eigenen Namen verfügt (42, s. Figur 7).

Speziell bei DNS-Verbindungen werden mehrere Sender (43, 48) zusammenge- fasst, indem zu der benannten Datenverbindung (42) mehrere Elternobjekte (36) zugelassen werden (s. Figur 8). Beim DNS-basierten„Loadbalancing", d.h. der Lastverteilung auf mehrere Zielsysteme mittels eines Verteilalgorithmus, z.B. round robin, bei dem die Zielsysteme reihum mit Transaktionen beauftragt werden, gibt es mehrere Empfänger (z.B. 60/55 bzw. deren Eltern 31 ), die über eine DNS-Verbindung angesprochen werden können. Auch hierfür wird die Da- tenverbindung im Metamodell vorteilhaft als eigenes Element modelliert. Auf dem Weg der Datenverbindung können ggf. transparente Dienste die Daten oder den Datenfluss beeinflussen. Beispielsweise können Firewalls die Erreichbarkeit bestimmter Ziele unterbinden, oder Loadbalancer können nach eigenen Algorithmen die Daten an verschiedene Ziele weiterleiten.

Auch Net Adress Translation (NAT) und Porttranslation können solche Dienste sein. Der Eingriff in eine Datenverbindung wird im Metamodell vorteilhaft als ein Kindelement (64, 66) zu einer benannten Datenverbindung (42) modelliert. So kann beispielsweise an eine benannte Datenverbindung eine Firewallregel (64) als Kindelement angehängt werden. Hierbei ist darauf zu achten, dass nur die Firewallregel als Kind angehängt wird. Die Firewall selbst wird als IT- Komponente (63) modelliert, da das technische Gerät seinerseits über IP- Verbindungen verwaltet wird (s. Figur 9). Mit der gleichen hier beschriebenen Methodik lassen sich auch andere synchrone und asynchrone Datenverbindungen beschreiben, z.B. Fiberchannel- Anbindungen, Filetransfers und Message-Queues.

Gemäß Anspruch 4 können die Strukturbäume übersichtlich und pflegbar struk- turiert werden, indem Gruppierungen von Elementen angelegt werden (s. Figur 10). Hierfür können sowohl mithilfe von Unique- als auch von Non-Unique- Elementen Gruppierungselemente modelliert werden, die auch über Attribute verfügen dürfen.

Für jede Gruppendarstellung entsteht ein eigener Zweig im Strukturbaum. Sol- che Substrukturen können auch dazu verwendet werden, um das IT-Verfahren unter unterschiedlichen Gesichtspunkten zu modellieren. Mithilfe von Primär- und/oder Sekundärrelationen können die Substrukturen miteinander verbunden werden. So können beispielsweise Gruppierungen modelliert werden, die das IT-Verfahren (77) einer generischen IT-Verfahrensgruppe (76, z.B. alle IT- Verfahren eines bestimmten Kunden) zuordnen. Das IT-Verfahren (77) seinerseits kann in einzelne Releases aufgeteilt werden (78, 79), und eine Plattformgruppe (88, auch Plattformbaum genannt), in der die physischen Komponenten konkret dargestellt werden. Dies ermöglicht eine effiziente und flexible Darstellung der Information über die Entwicklung des IT-Verfahrens über die unter- schiedlichen Releases hinweg (s. Figur 1 1 ). In Anspruch 5 ist beschrieben, wie die in Figur 13 dargestellten, zur Erstellung des Strukturbaums erforderlichen Informationen vorteilhaft erfasst und verwendet werden.

An der Bereitstellung eines IT-Verfahrens sind vom Vertrieb, über Servicema- nagement, Releasemanagement, Plattformbetriebsführung, IT- Verfahrensmanagement, etc. zahlreiche unterschiedliche Stationen (Rollen, Verantwortungsbereiche) beteiligt. Die Modellierung des erfindungsgemäßen IT-Verfahrens berücksichtigt all diese Stationen, um eine konsistente und automatisierbare Basis für ein umfassendes Management zu liefern.

Die Grundstruktur des Strukturbaums, der in den vorigen Ansprüchen dargestellt wurde, unterstützt dabei den gesamten Prozess.

Gemäß Anspruch 5 durchläuft der Prozess zur Erfassung der für eine vollständige Installation eines IT-Verfahrens erforderlichen Informationen folgende Schritte:

1 . Als Erfassungshilfe und auch zur leichteren Verknüpfbarkeit der technischen und der kaufmännischen Beschreibung eines IT-Verfahren empfiehlt es sich, mit Vorlagen (208) zu arbeiten. Besonders vorteilhaft ist hierbei ein Servicekatalog (197), der die standardisierten Leistungselemente beschreibt. Der Servicekatalog definiert die Leistungselemente, beschreibt diese Leistungselemente im Sinne eines Produktkatalogs, beschreibt diese Leistungselemente im Sinne des Strukturbaums strukturell als Vorlage und legt ein Preismodell für den Leistungsbezug fest.

Eine weitere Möglichkeit, Vorlagen in die Erstellung eines Strukturbaumes einzubeziehen, ist gegeben, wenn im Rahmen des Designs einer IT- Anwendung die Software mithilfe einer standardisierten Software-

Modellierungssprache erstellt wird. Dies kann beispielsweise in der bekannten Modellierungssprache UML (Unified Modeling Language) erfolgen. Die in der Software-Modellierung enthaltenen Informationen werden für die Erstellung der Grobstruktur des Strukturbaums verwendet. So kann beispielsweise im Rahmen des Designs einer Anwendung ein UML-

Diagramm (Server components, 198) erstellt werden. Dieser Diagrammtyp liefert Informationen über die Grundstruktur eines IT-Verfahrens. Hier sind die grundsätzlichen Verschaltungen des IT-Verfahrens enthalten, eventuell auch schon erste Festlegungen bezüglich der einzusetzenden Versionen, wie z.B. eines Betriebssystems oder eines Webservers„mindestens Version xx" etc. Dieses Bild gibt auch Informationen, ob eine bestimmte Software clusterfähig ist oder nicht.

Als Kopiervorlagen für das Erstellen eines Strukturbaums eines IT- Verfahrens lassen sich auch Referenzarchitekturen und sonstige technische Lösungen als verwenden. Technische Lösungen sind letztendlich identisch zu Leistungselementen des Servicekatalogs, mit dem Unterschied, dass hier noch kein allgemeingültiges Preismodell existiert, sondern dass die Preise individuell vereinbart werden. Aus Sicht der technischen IT-Verfahrenbeschreibung und deren Vorlagen, gibt es daher keine Änderungen. Referenzarchitekturen sollten sich im Idealfall aus Leistungselementen eines Servicekatalogs oder zumindest aus technischen Lösungen zusammensetzen. Somit wird die Referenzarchitektur als eine Vorlage angeboten, die im Normalfall mehrere Leistungselemente und technische Lösungen umfasst. Grundsätzlich bietet sie aber auch die Möglichkeit, weitere Elemente, außerhalb der Definitionen des Servicekatalogs und der technischen Lösungen, zu ergänzen.

Im Rahmen der Angebotserstellung (209, 210) an einen Kunden wird festgelegt, mit welchen Bausteinen, in welcher Skalierung eine Leistung für den Endkunden erbracht wird. Hier werden die kostenbestimmenden Faktoren Anzahl, Leistungsparameter und Typ der zu verwendenden Leistungselemente festgelegt, z.B. Anzahl einzusetzender CPUs, Hauptspeicher, Plattenplatz, Service- und Performancelevel. Dabei kann es sich beispielsweise darum drehen, wie viele Server welcher Art (124, 126, 129), Middleware-, Datenbank- und Applikations-Instanzen, auf welchen Umgebungstypen (125, 130 bzw. 127, 131 ), Betriebssystemen etc. zu welchem Preis und zu welchen Bedingungen (z.B. Servicelevel, Betriebszeit, ...) die Leistung erbringen sollen.

Um einen nachfolgenden Bereitstellungsprozess vollständig automatisieren zu können, ist es hier zwingend erforderlich, dass nur Leistungen angeboten werden, die einem gut strukturierten, datenbankgestützten Servicekatalog (197, 208) entstammen und damit maschinenlesbar sind. Deshalb ist es unbedingt erforderlich, dass bei der Angebotserstellung eine unter Punkt 1 ) definierte Struktur verwendet wird. Jede Nebenabrede, die in einer willkürlichen Art gespeichert würde, die nicht zu der unter Punkt 1 ) definierten Struktur passt, zerstörte die Automationsfähigkeit des Gesamtprozesses.

Die frühzeitige, strukturierte und vollständige Dokumentation der künftigen Umgebung hilft, die Bestellung fehlerfrei durchführen zu können. Durch die klare Dokumentation ist sichergestellt, dass kein zu beplanendes Leistungselement vergessen wird. Außerdem werden alle Leistungs elemente so vollständig beschrieben, dass diese im Nachhinein automatisiert installiert werden können. Die Beschreibung in diesem Schritt ist noch losgelöst von den konkreten Zielumgebungen, die erst anschließend durch die Plattform-Betriebsführungen (88) festgelegt werden. Die Beschreibung ist aber aus betrieblicher Sicht bereits konkreter als die Darstellung aus einer eventuell vorausgegangenen Softwareentwicklung da hier bereits alle Redundanzen und Mengen genau beschrieben sind. In Figur 23 ist dies illustriert.

Auf Basis der zuvor definierten Elemente und Mengenangaben wird für die neue Umgebung ein Angebot an den Endkunden erstellt. Für die einzelnen Bestelloptionen werden Leistungsscheinpositionen vergeben, die sich auf die Leistungsmodule im Servicekatalog beziehen. Ggf. nach mehreren Nachbesserungen erfolgt der Vertragsabschluss.

Nachdem der Endkunde dem Angebot zugestimmt hat und dieses beauftragt hat, erfolgt die Erfassung des IT-Verfahrens einerseits in den kaufmännischen Systemen (225), und andererseits ist die Erfassung für die automatisierte IT-Verfahrensinstallation (214) zu vervollständigen. Hier erfolgt die Erfassung des IT-Verfahrens inkl. der Spezialisierungen wie Gruppierungen, z.B. für das Bilden von Installationsgruppen und dem Anlegen von Datenverbindungen innerhalb des IT-Verfahrens und zu an deren IT-Verfahren. Die dargestellten Datenverbindungen beschreiben den„Nutzdatenverkehr" der Anwendung. Server und sonstige IT- Verfahrenselemente werden in dieser Darstellung non-unique beschrieben, da hier die korrekte Beschreibung eines einzelnen Releases im Vordergrund steht.

Jetzt werden all denjenigen IT-Verfahrenselementen aus dem Verfahrensbaum konkrete Plattforminstanzen, also z.B. Betriebssysteminstanzen, Server, Message Queuemanager, etc. in der Gruppierung des Platt formbaums zugewiesen (215 mit Unterstützung durch 220, 226), die von ihrer Plattform-Natur her mehrere gleichartige IT- Verfahrenselemente unterstützen können. Dies betrifft damit primär Server/ Betriebssysteminstanzen, Middlewarekomponenten und Netzkomponenten. Das Anlegen der Plattform-Elemente erfolgt unter Verwendung von Unique-Elementen. Die Zuweisungen erfolgen jeweils als Sekundärrelation vom IT-

Verfahrens-Element zum Plattform-Element mit der Maßgabe, dass ein IT-Verfahrens-Element nach Abschluss aller Zuweisungen genau einem Plattform-Element zugewiesen ist. Einige der Zuordnungen von den IT- Verfahrens-Elementen zu den Plattform-Elementen lassen sich direkt aus anderen Datenquellen erschließen. Z.B. die Zuordnung eines Servers zu seinem Netzwerkswitch. In diesen Fällen kann die Zuweisung automatisiert erfolgen.

Bei der Festlegung der Elemente sind alle konkreten Umgebungsbedingungen zu berücksichtigen:

a. Die anzuwendenden physischen Standorte: Bei verteilten Umgebungen ist sicherzustellen, dass die Anforderungen aus Sicht der Business Continuity eingehalten werden. Standorte werden gewählt unter dem Aspekt der Datenbeziehungen innerhalb und von/nach außerhalb des IT-Verfahrens und der Verfügbarkeit von Ressourcen und Netzbereichen.

b. Die anzuwendenden Netzsegmente und die speziellen IT- verfahrenstechnischen IP-Adressen werden festgelegt. IT- verfahrenstechnische IP-Adressen, z.B. Alias-Adressen für Webserver, sind unabhängig von den I P-Adressen der zugrundeliegenden Server.

c. Die Hostnamen physischer, logischer und virtueller Server werden festgelegt. Soweit noch nicht vorhanden, werden für die Server IP- Adressen für den normalen Datenverkehr, Backup und Systemmanagement vergeben. d. Die Namen der in Schritt 2) konkretisierten Middlewarekomponenten und Applikationen werden überprüft.

e. Es erfolgen plattformspezifische Zusatzangaben zu den Middleware- und Applikationskomponenten, wie zum Beispiel die Zuordnung von

IP-Adressen und Ports, falls dies noch nicht unter Schritt 2) erfolgt war. Außerdem weitere spezifische Angaben erfasst, wie z.B. bei MQ die Zuordnung der Queues zum dazugehörigen Queuemanager, f. Zu den einzelnen Elementen lassen sich elementspezifische Überwachungsaufgaben definieren, die insbesondere für die Überwachung des IT-Verfahrens wichtig sind. Bei guter Strukturierung dieser Aufgaben lassen sich diese mit einem hohen Standardisierungsgrad beschreiben, so dass die objektspezifischen Überwachungswerkzeuge damit automatisiert konfiguriert werden können. Der Erfassungsprozess setzt an etlichen Stellen manuelle Erfassungen der Informationen über das IT-Verfahren voraus. Ziel muss es sein, diese Erfassungen möglichst fehlerfrei und gleichzeitig möglichst unkompliziert und schnell durchführen zu können. In den Ansprüchen 6 und 7 werden Hilfsmittel bereitgestellt, die den Erfassungsprozess in diesem Sinne unterstützen.

Bei der manuellen Erfassung von Freitext kommt es hin und wieder zu Schreibfehlern. Um solche Fehler zu vermeiden werden über das Metamodell gemäß Anspruch 6 Vorgaben für wiederkehrende Ausdrücke definiert, die die Eingabemöglichkeiten des Nutzers beschränken. Zum Beispiel können solche, Regu- lar Expressions genannte Vorgaben vorschreiben, wie eine IP-Adresse oder eine Webadresse auszusehen hat, wann Groß- und wann Kleinschreibung zu verwenden ist, etc.

Eine weitere vorteilhafte Ausgestaltung der Erfindung gemäß Anspruch 7 trägt zur Vermeidung von Fehlern bei der Erfassung der Informationen für den Strukturbaum des IT-Verfahrens bei.

Viele Werte lassen sich aus Tabellen auswählen. Mittels des Value-Source- Mechanismus lässt sich die Zahl der auswählbaren Werte (95) aus einer großen Tabelle effizient einschränken, indem alle im Pfad oberhalb bereits erfassten Informationen zur Einschränkung der Zielmenge genutzt werden (s. Figur 14 (18)/(94) und (90)/(93) und (69)/(92)). Jeder Verweis auf eine Vergleichsspalte einer Auswahltabelle wird im Metamodell als je eine Bedingung formuliert. Die Bedingungen werden über eine UND-Verknüpfung zu einer Gesamtbedingung verbunden. Aus der Tabelle mit allen Einträgen würden nur die Werte angebo- ten werden (95), die die Gesamtbedingung erfüllen. Falls eine formulierte Bedingung zu Elementen bzw. Attributen nicht anwendbar ist, weil beispielsweise der Metaelementtyp der Bedingung in dem erfassten Baum nicht verwendet wurde, wird diese Bedingung übersprungen und nicht angewendet. D.h. der Nutzer erhält in diesem Fall eine größere Ergebnismenge.

Wird ein Attribut erfasst, so kann auch das Label des dazugehörigen Elements in der Auswahl berücksichtigt werden.

Weiterhin ist denkbar, dass an Stelle eines Zugriffs auf eine Datentabelle mit den gleichen Suchbegriffen ein entsprechender Zugriff auf ein API oder einen Webservice erfolgt. API oder Webservice geben entsprechende gültige Werte in Listenform zurück. Dies ist beispielsweise bei der dynamischen Ermittlung von gültigen IP-Adressen zu einem Element vorteilhaft.

In Anspruch 8 ist beschrieben, wie vorteilhaft verfahren wird, wenn bereits strukturierte Informationen zum IT-Verfahren vorliegen und automatisch in das Metamodell übertragen werden sollen.

Einige Topologien oder Topologiebestandteile des IT-Verfahrens können aus anderen Datenquellen direkt übernommen werden. So wird die Zuordnung von Netzkomponenten wie beispielsweise Switches zu Servern in Netzmanagementsystemen autark gepflegt, oder die Zuordnung von virtuellen Systemen zu Servern erfolgt autark unter Kontrolle eines eigenen Managementsystems.

Derartige vorgegebene Strukturen lassen sich häufig aus den Managementsystemen exportieren. Nach ein wenig Formatierung lassen sich diese Strukturen über den Bulk-Import (Massendatenimport) direkt in das Metamodell einlesen. Die einzulesende Struktur muss sich dabei auf ein eindeutiges Knotenelement beziehen unterhalb dessen die Massendatenstruktur einzulesen ist.

Der Bulkimport überwacht, dass nur erlaubte Beziehungen importiert werden. Importiert wird mehrstufig.

Zuerst werden die Elemente, Attribute, Primär- und Sekundärrelationen angelegt bzw. gelöscht. Dann werden die Relationen und Metatypen hinsichtlich ihrer Gültigkeit überprüft. Falls sich bei der Überprüfung herausstellt, dass min- destens eine Primärrelation oder mindestens ein Metatyp nicht gültig ist, wird der ganze Importvorgang abgebrochen.

Falls sich bei der Überprüfung herausstellt, dass Sekundärrelationen nicht mehr gültig sind, wird eine Fehlerliste erstellt, in der jede ungültige Sekundärrelation aufgeführt ist. Ungültige Sekundärrelationen müssen manuell kontrolliert wer- den, da diese ein Hinweis darauf sind, dass ein anderes Element von der weiteren Existenz und Gültigkeit dieser Relation ausgeht, die aber nicht mehr gilt. Ein solcher Bulk-Import lässt sich über einen Webservice oder ein ähnliches API auch online durchführen, ohne dabei die Erfindung zu verlassen.

Anspruch 9 beschreibt, wie bereits erfasste Teilstrukturen des Strukturbaums dupliziert und an anderer Stelle des Strukturbaums eingefügt werden können. Häufig müssen in den IT-Verfahren mehrfach Strukturen erfasst werden, die nahezu identisch sind. Zwischen diesen verschiedenen Teil-Strukturen ändern sich meist nur Servernamen, IP-Adressen oder ein bis zwei Attribute. Ansonsten sind diese Teilstrukturen vollkommen identisch. Um die Erfassung nicht immer wieder von Grund auf neu erstellen zu müssen, lässt sich eine erfasste Struktur über die Smart-Copy/Smart-Paste Funktion leicht duplizieren und im Rahmen der Duplikation anpassen.

Bei der Anpassung können die Eigennamen und die Attribute der Elemente geändert werden.

Elemente können weder gelöscht noch hinzugefügt werden. Alle Relationen bleiben innerhalb des kopierten Teilbaumes erhalten.

Elemente, die in dem Teilbaum nur über Sekundärrelationen angebunden sind, können nicht editiert werden, da zu diesen Elementen nur eine referenzierende Relation besteht.

Vor dem Einfügen eines kopierten Teilbaumes werden an der Stelle, an der er im Metamodell eingefügt werden soll, alle Metamodellbeziehungen auf ihre Gültigkeit geprüft. Erst wenn sichergestellt ist, dass der Teilbaum vollständig konform zum Metamodell ist, wird der Kopiervorgang physisch durchgeführt.

Optional können auch Relationen von Elternelementen, die außerhalb des aus- geschnittenen Baumes liegen, auf Kindelemente des kopierten Teilbaums beim Einfügen auf die neu erstellten Kindelemente übertragen (dupliziert) werden. Dies kann sowohl Primär- als auch Sekundärrelationen betreffen.

In Anspruch 10 wird beschrieben, wie im erfindungsgemäßen Metamodell vor- teilhaft die Voraussetzungen geschaffen werden, um den Strukturbaum in den Monitoring-Strukturbaum umzuwandeln.

Im serviceorientierten Monitoring und auch im serviceorientierten Reporting steht die Endnutzerperspektive im Vordergrund. Der Endbenutzer möchte einen Geschäftsprozess nutzen. Dieser Geschäftsprozess wird durch ein oder mehre- re IT-Verfahren unterstützt. Diese IT-Verfahren basieren auf der IT- verfahrensspezifischen Applikationssoftware, die auf Middlewarekomponenten und Servern bereitgestellt wird und die diverse Persistenzschichten, z.B. Datenbankinstanzen nutzt.

Der Monitoring-Strukturbaum ist damit unterhalb des IT-Verfahrens (Fig. 17, 77) gegenüber dem Installations-Strukturbaum gespiegelt.

Gäbe es keine Cluster, so hätte man damit bereits eine sehr einfache Abbildungsvorschrift zwischen den beiden Bäumen gefunden. Dieser einfache Fall ist in Figur 17 dargestellt. Links ist der Strukturbaum der Verfahrensinstallation, rechts der Monitoring-Strukturbaum dargestellt. Kommen Cluster ins Spiel, so ist die Konvertierung des Strukturbaums in den Monitoring-Servicebaum ungleich schwieriger. Bei Clustern müssen aus der Installationssicht heraus zunächst drei Funktionsweisen unterschieden werden: a) Die in Figur 18 dargestellte Applikationssoftware des geclusterten Elements sorgt intern für einen Datenabgleich zwischen den verschiedenen technischen Applikationsinstanzen, die sich nach außen als eine Instanz darstellen. Dies trifft z.B. auf ein Veritas-Cluster zu. Nach außen stellt das Veritas-Cluster eine Betriebssysteminstanz, z.B. Server-100c (104), bereit, die aber intern aus zwei physischen Servern, z.B. Server-100n (107), Server 200-n (108), gebildet wird. Fällt in diesem Fall z.B. der pri- märe Server-100n (107) aus, so übernimmt nach kurzer Übernahmezeit der sekundäre Server-200n (108) die Bereitstellung der Betriebssysteminstanz Serve OOc (104). Die Server können sowohl logische als auch virtuelle Server sein. Die Server müssen bereits aufgesetzt sein, bevor Veritas installiert wird. Deshalb erfolgt die Anbindung über Sekundärrela- tionen (13).

b) Die verschiedenen Instanzen werden über ein vorgeschaltetes DNS- basiertes Loadbalancing (auch bezeichnet als globales Loadbalancing) angesprochen. Die Instanzen dieses Clusters (53, 58) sind parallel aktiv (siehe Figur 19).

c) Die verschiedenen Instanzen werden über ein vorgeschaltetes aktives Loadbalancing (auch bezeichnet als lokales Loadbalancing) angesprochen. Die Instanzen dieses Clusters sind parallel aktiv.

Im Monitoring werden alle diese Cluster-Typen gleich dargestellt. Hier ist es aus Sicht eines IT-Verfahrens egal, wie das Cluster technisch bereitgestellt wird. Wichtig ist nur, dass dieses Cluster bereitgestellt und funktionstüchtig ist. Vergleicht man die drei Clustertypen, so stellt man fest, dass alle Clustervarian- ten jeweils durch ein gruppierendes Element eingeleitet werden, das ein Kind (ggf. Kindeskind) der IT-Verfahrensumgebung ist (Veritas-Cluster (104), DNS Datenverbindung (109) für globales Loadbalancing (1 10) und lokales Loadba- lancing (1 1 1 mit 36)). Durch diese Abbildung lässt sich die Monitoring-Sicht und auch die graphische Architekturdarstellung des IT-Verfahrens automatisch generieren, da die Abbildung eindeutig ist.

Um nun mit einem einzelnen Strukturbaum für die IT-Verfahrensinstallation und das Servicemonitoring auskommen zu können, müssen im Verfahrensbaum ei- nige Zusatzangaben gemacht werden. Der Verfahrensbaum ist insgesamt gesehen der detailliertere. Deshalb wird der Monitoring-Strukturbaum aus dem Verfahrens-Strukturbaum abgeleitet.

Für das serviceorientierte Monitoring benötigen Cluster Schwellwerte, ab denen der Ausfall einer vom Schwellwert definierten Anzahl dieser Cluster-Elemente im einem serviceorienterten Monitoringprozess dargestellt und ggf. als kritisch bewertet werden soll. Die hierfür notwendigen Schwellwerte werden den dazugehörigen Cluster-Gruppenelementen (Veritas-Cluster (104), DNS Datenverbindung (109) und lokales Loadbalancing (1 1 1 )) als Attribut mitgegeben, s. Figur 20.

Für das objektspezifische Monitoring von einzelnen Elementen (1 17) (z.B. Betriebssysteminstanzen, Middleware- oder Datenbankeninstanzen , jedes überwachbare Objekt) besteht die Möglichkeit im Strukturbaum zu definieren, mit welchem Monitoring-Werkzeug (1 18) diese überwacht werden und ggf. mit welchen Überwachungsaufgaben/-Skripten (1 19, 120, 121 ). Dies ist in Figur 21 dargestellt.

In einigen speziellen Fällen ist es sinnvoll, dass mehrere verschiedene Überwachungswerkzeuge ein Element überwachen. Daher wird hier das Überwa- chungswerkzeug (1 18) als Kindelement des überwachten Elements (1 7) modelliert. Das serviceorientierte Monitoring kann diese Information für die Klassifizierung der Events nutzen, um die Events im jeweils geeigneten Kontext darzustellen. Die einzelnen Elemente„Überwachungsaufgabe x" (1 19, 120, 121 ) umfassen jeweils eine maschinenlesbare Darstellung der Überwachungsaufga- be und die Beschreibung der dazugehörigen Handlungsanweisung bzw. das dazugehörige Fehlerbehebungsskript. Auf diese Weise hat man in den Struk- turbaum direkt eine Monitoring-Event-Datenbank integriert, die insbesondere für die IT-verfahrensspezifischen Überwachungen sehr hilfreich ist.

Anspruch 1 1 beschreibt, wie die generischen Strukturbäume angepasst werden können, um auch die unternehmensweite Architektursteuerung zu verwalten. Im Rahmen der unternehmensweiten Architektursteuerung werden die Zusammenhänge der IT-Verfahren aus der Perspektive der Geschäftsprozesse (102) benötigt. Die Geschäftsprozesse (102) werden durch ein oder mehrere IT- Verfahren bereitgestellt. Für die Release-Planung aus der Sicht eines Unter- nehmers sind deshalb die bestehenden technischen Abhängigkeiten zwischen den IT-Verfahren und innerhalb der IT-Verfahren relevant.

Der Strukturbaum für die IT-Verfahrensinstallation kann hier in zwei Richtungen wesentliche Beiträge liefern:

a. Da jede synchrone und asynchrone Datenverbindung modelliert ist, sind sofort alle technisch realisierten Beziehungen zwischen den IT-Verfahren darstellbar. Ebenso auch alle Datenverbindungen zu wesentlichen Plattform-Elementen.

b. Elemente lassen sich nur installieren, wenn genaue Versionsangaben vorliegen. Vergleicht man diese Versionsangaben mit den Releaseplänen der Hersteller der Elemente, erhält man für die unternehmensweite Architektur- und Lizenzsteuerung wesentliche Informationen.

Darüber hinaus lässt sich der Strukturbaum vorteilhaft für die automatisierte IT- Verfahrensinstallation auch noch so ergänzen, dass die jeweiligen Applikations- teile innerhalb der IT-Verfahren den Geschäftsprozessen (102) des Kunden zugeordnet werden. Dies wiederum kann eine Grundlage für die Einrichtung von aktiven End-to-End-Überwachungen (123) oder fachlichen Monitoringsystemen sein, siehe Figur 22. Sowohl den aktiven End-to-End-

Überwachungswerkzeugen (1 23) als auch den fachlichen Monitoringsystemen können Überwachungsaufgaben und Handlungsanweisungen bzw. Lösungsskripte (1 19, 120, 121 ) zugewiesen werden.

In Anspruch 12 ist ein Verfahren beschrieben, mit dem Teile eines Struktur- baums in ein Datenformat exportiert werden können, das die Darstellung hie- rarchisch strukturierter Daten unterstützt. Ein solches Dateiformat wird z.B. von der Extensible Markup Language (XML) gebildet.

Durch den Export der Serviceäume sind u.a. eine automatisierte Installation von IT-Verfahren und die automatisierte Konfiguration von Managementsyste- men, z.B. von Monitoringsystemen möglich. Diese Systeme können im Allgemeinen nicht direkt mit den internen Datenstrukturen der Strukturbaum- Beschreibung arbeiten. Für die Nachverarbeitung in diesen Systemen besteht daher die Möglichkeit, gemäß Anspruch 12 Teilbäume zu exportieren.

Von einem im Vorfeld vereinbarten Export-Startelement eines bestimmten Me- taelementtyps (z.B. GRP-Umgebung 137) werden im Teilbaum alle bis zum Endpunkt-Element baumabwärts angelegten Elemente mit ihren zugehörigen Relationen exportiert.

In einigen Fällen enthält der rein baumabwärtsgerichtete Export jedoch nicht alle Informationen, die man für die Installation eines IT-Verfahrens benötigt. Dies ist z.B. bei der Modellierung einer Datenverbindung der Fall. Bei dem in Figur 16 dargestellten Beispiel enthält der Export ab„Sender-Instanz" (30) alle Informationen bis hin zum Zielport (hier„80 http", 39). Im rein abwärtsgerichteten Export fehlt aber die Information, zu welcher IP-Adresse (38) und zu welcher Empfänger-Instanz (37) dieser Port gehört.

Um diese wichtige Information dem Export hinzuzufügen, werden bei definierten Relationen zusätzlich alle Relationen baumaufwärts exportiert. Aus Sicht des Exports wird der Baum damit an diesen Stellen gespiegelt und mitexportiert. Prinzipiell ließe sich dieser zusätzliche aufwärtsgerichtete Export bei jedem Element mitexportieren. Aus praktischen Erwägungen, insbesondere um den Export nicht unnötig groß zu machen, empfiehlt es sich jedoch, diesen gespiegelten Export nur dann durchzuführen, wenn er auch definitiv benötigt wird. Die Definition, wann der Export zusätzlich aufwärtsgerichtet bis zum Root Element (67) erfolgen soll, wird als Attribut an die zu dem relevanten Kindelement führende Metarelation angegeben. Bei der Definition ist zusätzlich unterscheidbar, ob aufwärts nur Primär- oder auch Sekundärrelationen exportiert werden sollen. Weiterhin ist es möglich, über einen API/Webservice Exporte von Strukturen in der beschriebenen Weise online durchzuführen.

Anspruch 13 beschreibt ein Verfahren zum Planen und Umsetzen eines Upgra- des für ein IT-Verfahren unter Verwendung von erfindungsgemäß angelegten Strukturbäumen. Beim Upgrade eines IT-Verfahrens ist es meistens nicht sinnvoll, das alte Release vollständig abzubauen und dann das neue Release vollständig neu aufzubauen. Aus diesem Grund ist es wünschenswert, die Unterschiede zwischen zwei Planungsständen von Releases, bzw. die Unterschiede zwischen zwei Teilbäumen zu ermitteln. Der Vergleich erfolgt gemäß Anspruch 13, indem zunächst der Strukturbaum des vorhandenen Releases in ein Dateiformat exportiert wird, das die Darstellung hierarchisch strukturierter Daten unterstützt, z.B. in XML. Dieser Teilbaum soll im Folgenden mit Teilbaum A bezeichnet werden. Anschließend wird der Strukturbaum des geplanten Releases erstellt und eben- falls in ein Dateiformat exportiert wird, das die Darstellung hierarchisch strukturierter Daten unterstützt. Der Strukturbaum des geplanten Releases sei im Folgenden mit Teilbaum B bezeichnet.

Da die Daten strukturiert in einheitlichen Formaten vorliegen, können sie automatisch, also mit Hilfe einer Datenverarbeitungsanlage verglichen werden. Die Ergebnisse des Vergleichs werden ebenfalls in strukturierter Form ausgegeben, wobei eine oder mehrere Dateien erstellt werden (s. Figur 15) .

Somit ist schnell ersichtlich, ob ein Element beim Upgrade mit all seinen Attributen verändert wird (96, 97), welche Elemente beim Upgrade gelöscht werden (99), welche Relationen beim Upgrade gelöscht werden (98) , welche Elemente beim Upgrade ergänzt wurden (87) und welche Relationen beim Update hinzugefügt wurden (100).

Weiterhin ist denkbar, dass man auch die Unterschiede zwischen ähnlichen Bäumen ermitteln kann. Dabei werden Bäume verglichen, indem vor dem Ver- gleich das Wurzelelement vom Teilbaum A umbenannt wird in das Label des Teilbaums B. Dies führt zu entsprechenden temporären Namensänderungen der Non-Unique-Kindelemente und Kindeskinder des Wurzelelements des Teilbaums A. Diese Namensänderungen können erfasst und beim Vergleich entsprechend behandelt werden, so dass mithilfe des erfindungsgemäßen Verfah- rens in vergleichbarere Weise Informationen über die Unterschiede zweier ähnlicher Bäume gewonnen werden können.

Weiterhin ist es möglich, über einen API/Webservice die Unterschiede zwischen zwei Planungsständen von Releases, bzw. die Unterschiede zwischen zwei Teilbäumen in der beschriebenen Weise online durchzuführen. Gemäß Anspruch 14 wird ein maschinenlesbares Speichermedium, z.B. eine CD-ROM, DVD, etc. so eingerichtet, dass die darauf gespeicherten Daten maschinell ausgelesen werden können, um dadurch so mit einem programmierba- ren Computersystem zusammenzuwirken, dass das Computersystem mindestens eines der in den Ansprüchen 1 bis 13 genannten Verfahren ausführt.

Gemäß Anspruch 15 wird ein Computer-Programm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode erstellt. Dieses Compu- ter-Programm-Produkt kann auf einem Computer laufen, so dass mindestens eines der in den Ansprüchen 1 bis 1 3 genannten Verfahren auf dem Computer ausgeführt wird.

Die Erfindung wird im Folgenden anhand von Ausführungsbeispielen näher erläutert.

Ein Anwender möchte ein IT-Verfahren von seinem PC aus über das Internet verwenden.

Im Rahmen der Angebotserstellung an einen Kunden wird nun festgelegt, mit welchen Bausteinen und in welcher Skalierung die gewünschte Leistung für den Endkunden erbracht wird.

Hierbei sollen die Bausteine aus einem gut strukturierten, datenbankgestützten Servicekatalog, z.B. dem Produktkatalog des Anbieters des IT-Betriebs für ein IT-Verfahren entnommen werden. Die Daten dieser Vorlagen sollen maschinen- lesbar sein.

Es ergibt sich in dem Beispiel, dass das IT-Verfahren einen Webserver und einen Applikationsserver benötigt.

Die Anzahl einzusetzender CPUs, Hauptspeicher, Plattenplatz, Service- und Performancelevel müssen festgelegt werden.

Ist die Konfiguration eines Elements nicht eindeutig über ein einzelnes Objekt beschreibbar, wird die Beschreibung über weitere Kindelemente zu dem Objekt ergänzt. Zum Beispiel kann eine Betriebssysteminstanz (18) unter mehreren I P- Adressen (19, 21 ) erreichbar sein oder mehrere IP-Dienste (20), (22) anbieten (s. Figur 5).

Als Webserver soll beispielsweise ein Apache Webserver (140) und als Applikationsserver ein JBOSS-JEE-Applikationsserver (141 ) verwendet werden, die miteinander so verknüpft sind (148), dass der Apache Webserver Daten an den ajp-Port (150 oben) des JBOSS-JEE-Applikationserver senden kann. Die Software-Applikation (142) soll auf dem JBOSS-JEE-Applikationsserver (141 ) laufen (s. Figur 24).

Als virtueller IT-Verfahrensserver, der Web- und Applikationsserver enthält, wird der OSS-Server KVA1 -206v (138) verwendet.

Das IT-Verfahren soll automatisiert installiert werden und in die unternehmensweite Architektursteuerung des Anwenders integriert werden. Weiterhin sollen ohne zusätzlichen Aufwand beim Anwender das Reporting über die Verfügbar- keit des IT-Verfahrens und seiner Elemente sowie ein serviceorientiertes Monitoring und Incident-Management des IT-Verfahrens gewährleistet sein. Darüber hinaus will der Anbieter ohne weiteren Verwaltungsaufwand die Leistungen abrechnen.

Dazu ist es erforderlich, die technischen und kaufmännischen Daten des IT- Verfahrens in einer definierten Struktur zu sammeln und zu verwalten, so dass alle für das Management des IT-Verfahrens relevanten Vorgänge automatisiert aus einer Datenquelle schöpfen können.

Hierfür werden alle Komponenten des IT-Verfahrens nun erfindungsgemäß selbstkonsistent, eindeutig und schleifenfrei modelliert.

Zunächst werden alle zulässigen Elementtypen definiert. Diese umfassen alle gängigen generischen IT-Komponenten, wie Server, Middleware, Storage etc. Weiterhin wird festgelegt, welche Attribute zu den Elementtypen zugelassen und/oder erforderlich sind und welche Primär- und Sekundärrelationen mit ihren zugehörigen Attributen zwischen den Elementen erlaubt sind.

Der virtuelle OSS-Server gehört zum Elementtyp Server, die Web- und Applikationsserver zum Elementtyp Middleware und die Software-Applikation zum Elementtyp Applikation. Die für die jeweiligen Elementtypen zugelassenen bzw. erforderlichen Attribute dienen dazu, die für die Installation und Betreuung des IT-Verfahrens relevanten Informationen zu erfassen und zu verwalten. Darüber hinaus können noch Zusatzinformationen angelegt werden.

Basierend auf diesen strukturierten Informationen wird nun ein Strukturbaum zur Beschreibung der Topologie des IT-Verfahrens erstellt, dem als Metastruktur ein azyklisch gerichteter Graph zugrunde liegt. Der Strukturbaum startet bei einem Wurzelelement. Alle Elemente des IT-Verfahrens werden nun hierarchisch in Eltern-Kind-Beziehungen unter dem Wurzelelement angeordnet. Durch den Formalismus der Metastruktur wird verhindert, dass einem Elternelement Kindelemente zugeordnet werden können, die ihrerseits bereits als deren Elternelement angelegt sind. Dadurch können unerwünschte Schleifen erst gar nicht entstehen (siehe Fig. 1 ).

Als Erfassungshilfe und auch zur leichteren Verknüpfbarkeit der technischen und der kaufmännischen Beschreibung des IT-Verfahrens empfiehlt es sich, mit Vorlagen zu arbeiten. Zentrales Element ist hierbei ein Servicekatalog, der die standardisierten Leistungselemente beschreibt.

Der Servicekatalog definiert die Leistungselemente. So ist der Apache-Server in diesem Beispiel ein Webserver bestimmter Ausprägung, basierend auf einem Linux-Server (OSS-Verfahrensserver) mit definierten Filesystemen. Im Servicekatalog sind diese Leistungselemente wörtlich im Sinne eines Produktkatalogs und strukturell im Sinne des Strukturbaums als Vorlage beschrieben. Außerdem enthält der Servicekatalog ein Preismodell für den Leistungsbezug.

Die Server sind in der Vorlage aus dem Servicekatalog auf Basis des Linux- Servers vormodelliert. Der virtuelle OSS-Verfahrensserver (138) ist über eine Primärrelation das Elternelement für die IT-Verfahrensinstallationsbasis (139), somit also die Grundlage für deren Installierbarkeit. Die IT- Verfahrensinstallationsbasis (139) definiert eine File- und Rechtestruktur, in die die weiteren IT-Verfahrenskomponenten (hier der Apache-Webserver (140) und der JBOSS-JEE-Applikationsserver (141 )) hinein installiert werden.

Die auf der IT-Verfahrensinstallationsbasis laufenden Middlewarekomponenten sind über Primärrelationen als deren Kindelemente angelegt.

Aus Gründen einer besseren Übersichtlichkeit ist in Figur 29 nur dargestellt, wie eine Vorlage für die Konfiguration Apache-auf-Linux in die Modellierung eines IT-Verfahrens übertragen wird. Die Vorlage für die hier verwendete Konfiguration eines Apache-Webservers und eines JBOSS-Applikationsservers auf einem Linux-Server (237) umfasst alle aus der IT-Verfahrenssicht benötigten Elemente, beginnend beim Linux-Server (237), über die IT- Verfahrensinstallationsbasis (Filesysteme, Gruppen, Rechte) (139) bis zu den beiden Middlewares Apache (239) und dem in Figur 29 nicht dargestellten JBOSS und allen datentechnischen Konnektivitäten (240, 241 , 242, 147, wiederum ohne JBOSS-Komponenten). Soweit möglich und sinnvoll, sind die Attri- bute zu den einzelnen Elementen mit Werten vorbelegt, z.B. mit den aktuellen Versionsnummern des Linux-Betriebssystems und der Middlewareserver. Die Vorlage wird dann mittels des Smart Copy-Mechanismus (243) in die IT- Verfahrensbeschreibungen (rechts in Figur 29) übertragen.

Hierbei werden die vorgegebene Struktur dupliziert und die Eigennamen und Attribute der Elemente angepasst. Im Rahmen des Smart Copy-Vorgangs (243) können Elemente weder gelöscht noch hinzugefügt werden. Alle Relationen bleiben innerhalb des kopierten Teilbaumes erhalten. Elemente, die in der Vorlagenstruktur nur über Sekundärrelationen angebunden sind, können nicht editiert werden, da zu diesen Elementen nur eine referenzierende Relation besteht.

Vor dem Einfügen des kopierten Teilbaumes in den zu erstellenden Strukturbaum des IT-Verfahrens werden an der Stelle, an der er im Metamodell eingefügt werden soll, alle Metamodellbeziehungen auf ihre Gültigkeit geprüft. Erst wenn sichergestellt ist, dass der Teilbaum vollständig konform zum Metamodell ist, wird der Kopiervorgang physisch durchgeführt.

Im Beispiel wird die Vorlage„Apache-und-JBOSS-auf-einem-Linux-Server" einmal im Rahmen der IT-Verfahrensbeschreibung verwendet. Es ergibt sich der Strukturbaum aus Figur 24. Bei dem Kopiervorgang werden einige der Vorgabewerte manuell ersetzt, z.B. wird die I P-Adresse 172.x.y.z des Apache- Servers ersetzt durch 172.1 7.75.87 (144).

Ebenso können im Rahmen des Kopiervorgangs auch Attribute verändert werden.

Wichtig ist, dass bei der Verwendung von Kopiervorlagen gültige Regeln des Metamodells nicht unterlaufen werden. In dem in Figur 29 gezeigten Beispiel wurde z.B. als Metaelementtyp für die Kopiervorlage„GRP-Vorlage-Linux; Apa- che-auf-Linux" (236) definiert. Erstes Kind dieser Kopiervorlage ist der Metaelementtyp„OSS-Linux-Server-virtuell" (237). Über das Metamodell ist sicherzustellen, dass der Metaelementtyp der Kopiervorlage (hier „GRP-Vorlage- Linux; Apache-auf-Linux" (236)) nur an den Stellen zum Einsatz kommen darf, an denen auch der Metaelementtyp„OSS-Linux-Server-virtuell" (237) zum Ein- satz kommt. Es ist folglich nicht möglich, einen allgemeinen Elementtyp„Vorlage" zu definieren, der alle Elementtypen als erstes Kind aufnimmt. Sonst würde es über diesen Weg z.B. möglich, dass eine Middlewarekomponente (140) ohne Server (247) direkt an eine IT-Verfahrensumgebung (245) angehängt würde, was technisch wegen des dann fehlenden Betriebssystems nicht lauffähig wäre. Man benötigt somit für jeden Kindelementtyp, der eine Vorlage einleitet (hier z.B. den Linux-Server-virtuell (237)), jeweils eigene Metaelemente (hier z.B. „GRP-Vorlage-Linux; Apache-auf-Linux" (236)) zur Definition der Kopiervorlagen. Man benötigt aber nicht für jedes Leistungselement des Servicekatalogs ein eigenes Metaelement. So ist es beispielsweise problemlos möglich, auf Basis des Metaelementtyps „GRP-Vorlage-Linux" alle Vorlagen aufzubauen, die auf Basis eines Linux-Servers erlaubt sind, z.B. Apache-auf-Linux (236), JBOSS-auf-Linux, Apache-und-JBOSS-auf-einem-Linux-Server, Apache-und- Linux-auf-zwei-getrennten-Linux-Servern, u.s.w.

Nach dem Einfügen der Vorlage Apache-und-JBOSS-auf-einem-Linux-Server in unserem Beispiel in Figur 24 wird dann die auf dem JBOSS-Server installierte Applikation KVA1 -JEE (142) als ein Kindelement des JBOSS-Servers (141 ) angelegt.

In diesem Beispiel wäre es auch denkbar, dass als Vorlage ein UML-Diagramm verwendet wird, das im Rahmen der Entwicklung einer neuen Anwendung für das IT-Verfahren entwickelt wird.

Die zu entwickelnde Anwendung wird dann in der Modellierungssprache UML modelliert. Hieraus wird ein UML-Diagramm erstellt, das bereits Informationen über die grundsätzliche Struktur des IT-Verfahrens enthält. Dieses UML- Diagramm (198) wird konvertiert, so dass es als Vorlage (208) für die erfin- dungsgemäße IT-Verfahrensbeschreibung verwendbar ist. Diese Vorlage enthält Informationen darüber, welche Elementtypen in dem IT-Verfahren verwendet werden und wie diese miteinander über Installationsvoraussetzungen und Datenverbindungen verknüpft sind. So ergibt sich in diesem Beispiel unterhalb des Wurzelelements„Root" der in Figur 24 gezeigte Strukturbaum.

Auf der linken Seite sind zunächst die übergeordneten GRP-Elemente (135 - 137) der IT-Verfahrensbeschreibung angelegt. Sie dienen der Strukturierung der IT-Verfahren des Kunden A. Das hier betrachtete IT-Verfahren ist genauer spezifiziert durch die untergeordneten Elemente Kundenverfahren A1 (136). Dem zugeordnet ist die GRP-Umgebung Produktion (137). Daran schließen sich die bereits genannten IT-Verfahrensserver an.

Auf der rechten Seite sind unter dem übergeordneten Element GRP-Bereich RZ-Produktion (152) die IT-Plattformen aufgeführt, die von den IT-Verfahren genutzt werden können. Diese physischen Komponenten sind mithilfe von Se- kundärrelationen (13) den virtuellen Komponenten aus der IT- Verfahrensbeschreibung zugeordnet.

Einige der Attribute und Zusatzinformationen zu den Elementen sollen im Folgenden vorgestellt werden.

Um eine Betriebssysteminstanz (d.h. einen virtuellen Server) in einem Rechenzentrum korrekt zu installieren, werden Angaben zur geforderten Leistungsklasse (CPU-Leistung, Hauptspeicher, ...), sowie sicherheitstechnische Angaben (z.B. Aufstellungsort/Brandabschnitt, ...) benötigt. Diese Angaben sind dann auch bei der Zuweisung zu einem physischen Server zu berücksichtigen, sowie bei der Zuweisung der I P-Adressen. Der virtuelle OSS-Server muss demnach durch diese Attribute beschrieben werden.

Die IT-Verfahrensinstallationsbasis (139) definiert eine File- und Rechtestruktur, in die die weiteren IT-Verfahrenskomponenten (hier der Apache-Webserver (140) und der JBOSS-JEE-Applikationsserver (141 )) hinein installiert werden. Typische Attribute für diese IT-Verfahrensinstallationsbasis sind:

• Username und UserlD

• Groupname und GroupID

• Pfad und Filesize

• Backupvorgaben

• Sicherheitszone

• Installationsreihenfolge (Null = default; positiver Wert = erste, zweite, dritte; negativer Wert = letzter, vorletzter, ...) Für die diversen Middlewarekomponenten, wie z.B. den Apache Webserver (140) oder den JBOSS-JEE-Applikationsserver (141 ), werden spezielle Parameter benötigt, z. B. die Versionsnummer der Middleware, ggf. die Versionsnummer einer direkt damit verbundenen Komponente wie die der zugrundeliegenden Java virtuellen Maschine, Angaben zum Startverhalten und zum Backup oder Angaben zum Servicelevel der Middlewarekomponente.

Viele Detailangaben, wie z.B. die Standardfilesysteme dieser Middlewarekomponenten müssen nicht modelliert werden. Alles das, was sich implizit ergibt, sollte nicht mit modelliert werden. Im Vordergrund sollte immer stehen, dass nur das modelliert wird, was auch zwingend aus IT-Verfahrenssicht modifiziert werden können muss. Auch zu den Applikationen (142) gibt es spezielle Angaben, z.B. die Version der Applikation oder Pfadangaben zum Auffinden der Applikation.

Beim Anfordern der IP-Adresse und auch für nachfolgende Entscheidungen (z.B. bei Firewallregeln) muss klar sein, in welchem Netzsegment und welchem VPN die IP-Adresse benötigt wird. Hinzukommt, dass serverseitig häufig mehrere Netzwerkkarten zur Verfügung stehen. Hier möchte man ggf. festlegen, über welches dieser Interfaces die IP-Adresse geroutet werden soll. Beim IP-Dienst muss klar definiert sein, welcher IP-Dienst (Name, z.B. http, https, ajp, ...) welchem Port oder Portrange zugewiesen wird, und ob die Ports für UDP oder TCP anzulegen sind.

Wenn der Strukturbaum des IT-Verfahrens erstellt ist, wird er gemäß Figur 28 dann der kaufmännischen Analysemethode (Kfm, 219) übergeben, die aus diesen Angaben die benötigten Artikelnummern des Servicekatalogs (1 97) ermittelt (224) und hiermit dann eine erste Preisinformation für den Kunden erstellt. Die kaufmännische Behandlung könnte auch bereits erfolgen, wenn noch nicht alle technischen Details bekannt sind. Für die kaufmännische Behandlung ist es nämlich beispielsweise irrelevant, ob die IP-Adresse 172.12.13.14 vergeben wird, denn es kann ausreichend sein, zu wissen, dass überhaupt eine IP- Adresse angefordert wird, und evtl. ist selbst diese Information kaufmännisch betrachtet obsolet.

Ist das Interesse beim Besteller des IT-Verfahrens geweckt, so wird wiederum mit Hilfe des kaufmännischen Analysemethode (Kfm, 219) ein konkretes Angebot (210) angefordert und ein Vertrag abgeschlossen und hinterlegt (225). Da ein Angebot eine rechtliche Verbindlichkeit hat, wird vor der Anforderung des Angebots, die IT-Verfahrensbeschreibung in den Mandanten„Soll kaufmännisch" (21 1 ) übertragen, in dem während der Erstellung eines Angebots keine Änderungen gemacht werden können. Mit Vertragsabschluss wird dieser Stand in den Mandanten„Ist kaufmännisch" (212) übertragen. Das Angebot kann entweder für die komplette IT-Verfahrensumgebung angefordert werden, oder (durch Vergleich von„Soll kaufmännisch" und„Ist kaufmännisch") nur in dem Umfang der erforderlichen Änderungen (199) .

Ist das Angebot fehlerfrei, was durch die Analysemethode„QS kaufmännisch" (200) ermittelt wird, und ist die Beauftragung der Implementierung vom Vertrieb freigegeben, so erfolgt die detailliertere Beplanung des IT-Verfahrens im Mandanten Planung (213) durch das Releasemanagement (214) und die Systemplanung (215). Die Analysemethode„QS-kaufmännisch" (200) prüft, ob gültige Artikelnummern ermittelbar waren und ob komplexere Abhängigkeiten (z.B. wenn Element A mit hohem Servicelevel bestellt ist, dann muss auch B mit hohem Servicelevel bestellt sein) erfüllt sind. Die Methode liefert auch Hinweise im Sinne von Warnungen, wenn gravierende Unterschiede zwischen dem alten und dem künftigen neuen Vertrag bestehen, z.B. Preissteigerung über 10%. Die Systemplanung (und ggf. auch das Releasemanagement) werden durch die Analysemethode„Systemplanung" (220) unterstützt. Z.B. bei der Bestellung/Vereinbarung einer I P-Adresse werden Strukturinformationen ausgewertet, wie z.B. ob die I P-Adresse zu einem Server in der Produktions- oder Abnahmeumgebung gehört, in welchem Sicherheitsbereich die I P-Adresse benötigt wird und welche Middleware auf dem Server bereitgestellt werden soll. Analog wird bei der Zuweisung von Storage verfahren. Mit der Analysemethode„Systemplanung" (220) wird insbesondere das Kapazitätsmanagement (226) unterstützt. Nachdem die Planung abgeschlossen ist, wird die durchgeplante IT- Verfahrensbeschreibung zunächst qualitätsgesichert.

Im Rahmen der kaufmännischen Qualitätssicherung (200) wird zunächst ge- prüft, ob es keine Abweichungen (199) zwischen dem Planungsstand und dem Stand„kaufmännisch Soll" oder„kaufmännisch Ist" besteht (je nachdem, ob die Workflows in den kaufmännischen Systemen bereits abgeschlossen oder noch in Arbeit sind. Hier dürfen keine Abweichungen gemeldet werden. Treten Abweichungen auf, so ist sicherzustellen, dass die kaufmännischen Systeme kurz- fristig mit dem Planungsstand in Übereinstimmung gebracht werden, aber nur dann, wenn der Planungsstand allen fachlichen (kaufmännischen und technischen) Anforderungen genügt.

Im Anschluss daran erfolgt die technische Qualitätssicherung (207). Hier werden aus technischer Sicht diverse Prüfungen durchlaufen, z.B. ob die zugewie- sene IP-Adresse den Anforderungen des Servers genügt. Diese Prüfung ist erforderlich, da nicht ausgeschlossen werden kann, dass durch die nachträgliche Änderung eines Attributs sich die Entscheidungskriterien für die Zuweisung gerade dieser IP-Adresse nicht doch noch geändert haben. Sollte dies der Fall sein, so muss die Planung entsprechend geändert werden, bevor die Anwen- dung zu installieren ist. Die Planung ist nun abgeschlossen. Sobald der Vertrieb das Startsignal gibt, kann mit der Installation begonnen werden.

Sind alle Qualitätssicherungsmaßnahmen erfolgreich durchlaufen, wird der Planungsstand in den Mandanten„To-be-installed" (21 7) übertragen, wo er nicht mehr verändert werden kann. Die QS-Routinen bestätigen hier final die Korrektheit der Planung. Danach beginnt die Installation. Die Analysemethode„In- stall" (221 ) ermittelt die Installationsaufgaben und lässt diese ausführen. Die Ausführung erfolgt entweder automatisiert durch geeignete Installationsskripte (227) oder durch die Erstellung von Änderungsaufträgen an das Changemana- gement (228). Alle diese Aufgaben laufen unter der Kontrolle von„Install" (221 ) ab.

Nach Abschluss aller Installationsaufträge meldet„Install" (221 ) die Umsetzung an die Abrechnungssysteme (229), so dass dem Kunden des IT-Verfahrens nun Rechnungen gestellt werden können.

Die Analysemethode„Mon" (222) aktualisiert die Monitoringaufträge sowohl für die objektspezifischen Monitoringsysteme (231 ) der Plattform (Unix- Überwachung, Webserver-Überwachung, Applikationsüberwachung etc.), als auch für das zentrale Business Service Monitoring (230), in dem die Alarmmeldungen aus den unterschiedlichen objektspezifischen Monitoringsystemen mit- einander korreliert werden.

Die Analysemethode „Gov" (223) überträgt Informationen aus dem Installed- Mandanten (218) in das Enterprise Architektur Management (232). So z.B. Informationen zu den verwendeten Komponenten und deren Versionsständen und Informationen zu den technischen Datenbeziehungen in den IT-Verfahren.

In einem zweiten Beispiel wird ein gegebenes IT-Verfahren erweitert um einen separaten Datenbankserver (160) und um einen Client (159). Dies ist in der Figur 25 dargestellt.

Die Endgeräte werden nicht einzeln modelliert. Damit aber Firewall-Regeln au- tomatisiert erstellt werden können, müssen die Gruppen an Endgeräten im IT- Verfahren dargestellt werden. Hier wird exemplarisch ein Client dargestellt, der über das Internet auf das IT-Verfahren zugreift. Über Attribute erhält dieser Client (Typ OSS-Endgerätegruppe) die Information, über welches VPN er zugreift.

Die Datenbank wird zunächst genauso modelliert wie jede andere Middleware- Komponente. Es wird ein virtueller Server (160) modelliert, auf dem eine IT- Verfahrensinstallationsbasis (139) für die Datenbank (161 ) angelegt wird (d.h. Filesysteme, Gruppen und Rechte). Auf dieser IT-Verfahrensinstallationsbasis wird dann die Datenbank (161 ) angelegt. Die Datenbank erhält über Attribute einige Zusatzinformationen, die für die Installation der Datenbank wichtig sind, so z.B. die Datenbankversion, das Character-Set, die SID, Angaben zu den Größen der benötigten Filesysteme und zu dem Backupverfahren.

Über weitere Kindelemente zur Datenbankinstanz lassen sich zusätzlich anzuwendende Patches oder Softwareoptionen beschreiben. Auch die Einrichtung von Tablespaces lässt sich so beschreiben.

Datenbankcluster wie z. B. Oracle-Dataguard werden beschrieben, in dem sie als Elternelement oberhalb der Oracleinstanzen eingeschoben werden.

Im nächsten Beispiel wird ein gegebenes IT-Verfahren um einen Strang ergänzt, der über einen globalen Loadbalancer adressiert wird. In Figur 26 ist dargestellt, wie zwei verschiedene Clientgruppen (159, 165) den DNS-Dienst (233) nutzen, um eine Farm von Webservern anzusprechen. Die Clients adressieren die DNS-Adresse www.kva 1.com. Der DNS-Dienst löst diese Adresse auf und gibt als Zieladresse wechselweise die I P-Adressen und Ports der beiden Webserver aus (d.h. 172.17.75.87 (234) oder 172.17.75.88 (166) mit Port 80j. In welcher Reihenfolge die Anfragen mit der einen oder anderen Adresse beantwortet werden, ergibt sich aus dem gewählten Loadbalancing-Verfahren. Meistens wird dies round-robin sein. Das Loadbalancing-Verfahren wird als Attribut bei der DNS-Adresse angegeben. Die DNS-Adresse { www.kva 1.com) wird von dem IT-Verfahrensbetriebsführer verantwortet. Sie gehört zum jeweiligen IT-Verfahrenskontext und ist für die jeweiligen DNS-Dienste eindeutig. Daher wird diese DNS-Adresse unique modelliert. Sie ist primäres Kind der IT-Verfahrensumgebung (1 37). Genutzt wird diese DNS-Adresse, indem sie als sekundäres Kind einer oder mehrerer Daten- Verbindungen abgehend (147) definiert wird und ihrerseits die Zielports (146) als sekundäres Kind erhält.

In einem weiteren Beispiel wird die Verwendung von Unique- und Non-Unique- Elementen erläutert: Ein Apache (82) wird auf einem Server (80) installiert, der in Release 1 (78) und Release 2 (79) verwendet wird. Nun wird im Release 2 (79) ein weiterer Apache (Apache2, 81 ) auf diesem Server (80) installiert.

Würde der Server unique modelliert, so könnte über den Baum nur über zusätz- liehe Attribute oder Verknüpfungen ausgedrückt werden, dass der Apache2 (81 ) nur im Release 2 (79) gültig ist (s. Figur 1 1 ).

Modelliert man den Server non-unique, so kann man bereits über den Strukturbaum ausdrücken, dass im Release 1 (78) Apachel (85) und im Release 2 (79) Apachel (86) und Apache2 (87) relevant sind. Der Server (83, bzw. 84) erhält in dieser Variante seinen Namen (nicht das Label) mit Bezug auf das Elternelement Release. Man verliert aber in dieser Darstellung die Information, dass die Server (83 und 84) in Release 1 (78) und Release 2 (79) identisch sind. Das Label ist zwar gleich, nicht aber der Name.

Um nun doch direkt im Strukturbaum ausdrücken zu können, dass die beiden Apachel und Apache2 in den beiden Releases auf dem physisch gleichen Server laufen, wird der Server zweimal modelliert: Im sogenannten Verfahrensbaum (links in Figur 12, unterhalb der Verfahrensgruppe (76)) wird er non- unique modelliert (83 bzw. 84). Im Plattformbaum (rechts in Figur 12, unterhalb der Plattformgruppe (88)) wird er unique modelliert (89). Über eine Sekundärrelation (13) wird jeweils der Bezug zwischen diesen Serverbeschreibungen hergestellt, s. Figur 12. In dieser Kombinationslösung wird der Plattformbaum über Importmechanismen direkt bereitgestellt. Die Erfassung des Verfahrensbaums und die Verknüpfung zu den Elementen im Strukturbaum erfolgt manuell im Rahmen der Beauftragung der Übernahme der Betriebsführung.

Ein weiteres Beispiel beschreibt, wie die Informationen aus dem Strukturbaum zur automatisierten IT-Verfahrensinstallation benutzt werden.

Für die automatisierte Installation werden beispielsweise alle Informationen in einem geeigneten Format, z. B. in XML exportiert (oder in einem API bereitgestellt) und einem Installationsautomaten übergeben. Der Installationsautomat ermittelt aus dem Baum für jedes Element die vollständigen Installationspara- meter und legt die Installationsreihenfolge der Elemente fest. Die Installationsparameter für jedes Element findet der Automat in den Attributen der IT- Verfahrens-Elemente, sowie in den Attributen seiner Eltern und Kindelemente, und eventuell noch in den Attributen der Eltern- oder Kindelemente eines seiner Kindelemente. Elementspezifische Konfigurationen, sowie Tuningparamter sind über Verweise auf andere Datenquellen zugänglich. Ggf. werden in diesem Schritt auch noch die Unterschiede zwischen bestehendem und künftigem Releasestand der IT-Verfahrensumgebung ermittelt, so dass nur die Änderungen installiert werden müssen.

Bei der Ermittlung der Installationsaufgaben (175) wird z.B. festgestellt, dass ein Linux-Server, ein Apache-Webserver, ein Applikationsserver und eine Datenbank installiert werden sollen. Der Algorithmus stellt in diesem Beispiel fest, dass die Datenbank bereits geeignet in einem vorangegangenen Release installiert wurden, daher diese Installationsaufgabe übersprungen werden kann. Die Reihung der Aufgaben sequentialisiert die Installationsaufgaben und bringt diese in eine geeignete Abfolge. So wird entsprechend zuerst der zugrundeliegende Linux-Server installiert bevor der Apache-Webserver installiert wird. Damit die Installationsaufgabe auch durchgeführt werden können, muss an die Installationsskripte ein jeweils geeignetes Parameter-Set übergeben werden. Auch dieses wird aus dem Baum heraus ermittelt. Die eigentliche Installation wird durch eine Workflowkomponente überwacht. Die einzelnen Installationsaufgaben werden entweder durch geeignete Skripte durchgeführt, oder es werden Arbeitsaufgaben in das Changemanagement eingestellt, die dann manuell von den zuständigen Betriebsführern durchzuführen sind. Der Installationsstatus wird an das Assetmanagement und das Kapazitätsmanagement übermittelt.

Abschließend können Auszüge aus den im Strukturbaum erfassten Informationen auch noch an das Enterprise Architektur Management übergeben werden (178). Die Informationen unterstützen die Planung beispielsweise, indem für jedes IT-Verfahren / jede Umgebung jeweils für alle Elemente die aktuell ver- wendeten Versionsnummern bekannt sind, oder indem alle technischen Datenbeziehungen zwischen verschiedenen IT-Verfahren bereitgestellt werden können. Dies unterstützt den Abgleich gegen fachlich bekannte Datenbeziehungen zwischen den IT-Verfahren. Im Rahmen des Installationsprozesses, spätestens an dessen Ende, wird eine Information an das Financial-Management (229) zurückgegeben, die über die Bereitstellung des IT-Verfahrens und den Leistungsbeginn informiert. Somit kann dann mit der Verrechnung der Leistungen begonnen werden.

Zum Schluss soll noch kurz anhand der Figuren 29 und 30 auf die Verwendung von Vorlagen für die Modellierung häufig verwendeter IT-Verfahrensteile näher eingegangen werden.

In Figur 29 ist beispielhaft dargestellt, wie eine Vorlage für eine technische IT- Verfahrensbeschreibung aussehen kann (links) und wie sie verwendet wird, um ein IT-Verfahren zu modellieren (rechts). Die Vorlage für die hier verwendete Konfiguration eines Apache-Webservers auf einem Linux-Server (236, mit zugehörigen Kindelementen 237 bis 242, 139, 147) umfasst die Basisdarstellungen aller aus der IT-Verfahrenssicht benötigten Elemente, beginnend beim Linux-Server (237), über die IT-Verfahrensinstallationsbasis (139) (Filesysteme, Gruppen, Rechte) bis zur Middleware Apache (239) und allen datentechnischen Konnektivitäten (238, 240, 241 , 242, 147). Soweit möglich und sinnvoll, sind die Attribute zu den einzelnen Elementen mit Werten vorbelegt, z.B. mit den aktuellen Versionsnummern des Linux-Betriebssystems und des Apache-Webservers. Im zu modellierenden IT-Verfahren kann die Vorlage für jeden der beiden Apache-Webserver (246, 252) verwendet werden.

Bei dem Kopiervorgang werden einige der Vorgabewerte manuell ersetzt, z.B. wird die IP-Adresse 172.a.b.c (240) aus der Basisdarstellung des Apache- Servers (239) in der Vorlage nach dem Smartcopy-Vorgang in der Beschreibung des Apachel (140) im IT-Verfahren ersetzt durch 172.17.75.87 (249). Ebenso können im Rahmen des Kopiervorgangs auch Attribute verändert wer- den.

Figur 30 zeigt, wie eine Referenzarchitektur (260, mit zugeordneten Kindelementen) Leistungselemente eines Servicekatalogs (235, mit zugeordneten Kindelementen) und technische Lösungen (254, mit zugeordneten Kindelemen- ten) als Beschreibungsgrundlage verwendet. Die Referenzarchitektur (260, mit zugeordneten Kindelementen) steht dann als eigenständige Kopiervorlage für die rechts dargestellte Modellierung einer IT-Verfahrensbeschreibung zur Verfügung. Links oben ist die aus Figur 29 bekannte Vorlage für die Konfiguration eines Apache-Webservers auf einem Linux-Server dargestellt. Links unten ist eine Vorlage aus dem Bereich der technischen Lösungen dargestellt, bei der ein Informationsserver (258) auf einem OSS-Windows-Server (256) angelegt ist. Auf dem Informationsserver (258) sind als Anwendung ein Dokumentationssystem (259) und alle datentechnische Konnektivitäten (240, 241 , 242, 147) angelegt.

Bei der auf der rechten Seite dargestellten Modellierung des IT-Verfahrens können sowohl die Referenzarchitektur als auch weitere, einzelne Elemente aus dem Servicekatalog bzw. aus den technischen Lösungen verwendet werden. Allgemein wäre jede beliebige Kombination aus Referenzarchitekturen, Leistungselementen aus dem Servicekatalog, technischen Lösungen und sonstigen Elementen (z.B. 253 und 272) denkbar. So sind in der in Figur 30 rechts dargestellten Modellierung des IT-Verfahrens mithilfe des Smart-Copy- Verfahrens (243) sowohl die zuvor beschriebene Referenzarchitektur (261 , mit zugehörigen Kindelementen) als auch ein weiterer Apache auf Linux (Apache- auf-Linux-2, 252 mit zugehörigen Kindelementen) eingefügt worden; darüber hinaus wurden noch als sonstige Elemente ein OSS_Server-virtuell; z/OS Host (253) und das Spez-Doku-System (272) angelegt.

Bezugszeichenliste

1. Elternelement

2. Kindelement 1

3. Kindelement 2

4. zulässige Eltern-Kind-Beziehungen

5. unzulässige Eltern-Kind-Beziehung

6. Unique-Element, Label = Elemente, Name = Elemente

7. Unique-Element, Label = ElementA, Name = ElementA

8. Non-Unique-Element, Label = Elemente, Name = ElementB_ElementC

9. Non-Unique-Element, Label = ElementD,

Name = ElementB_ElementC_ElementD

10. Referenz

1 1 . Elementtyp U, Label = ElementA

12. Elementtyp V, Label = Elemente

13. zulässige Sekundärrelation

14. unzulässige Sekundärrelation

15. a) Elementtyp W, Label = ElementE

15. b) Elementtyp W, Label = ElementD

16. Primärrelation

17. IT-Verfahren

18. Betriebssystem-Instanz (Bl)

19. IP-Adresse Bl

20. IP-Port Bl

21 . IP-Adresse Bl backup

22. IP-Port Bl backup

23. Middleware Apache-Server (AS)

24. IP-Adresse AS

25. IP-Port 1 AS

26. IP-Port 2 AS

27. Middleware JBOSS-Applikationsserver (JBOSS)

28. IP-Adresse JBOSS

29. IP-Port JBOSS

30. Sender-Instanz

31 . Gruppierung Datenempfänger

32. IP-Adresse 1 33. IP-Port 1

34. IP-Adresse 2

35. IP-Port 2

36. Gruppierung Datensender

37. Empfänger-Instanz

38. IP-Adresse 3

39. IP-Port 3

40. IP-Adresse 4

41 . IP-Port 4

42. Benannte Datenverbindung

43. Sender-Instanz 1

44. IP-Adresse 1 Sender-Instanz 1

45. IP-Port 1_Sender-lnstanz 1

46. IP-Adresse 2 Sender-Instanz 1 _

47. IP-Port 2 Sender-Instanz 1

48. Sender-Instanz 2

49. IP-Adresse 1 Sender-Instanz 2

50. IP-Port 1 Sender-Instanz 2

51 . IP-Adresse 2_Sender-lnstanz 2

52. IP-Port 2 Sender-Instanz 2

53. Empfänger-Instanz 1

54. IP-Adresse_1 Empfänger-Instanz 1

55. IP-Port 1 Empfänger-Instanz_1

56. IP-Adresse 2 Empfänger-Instanz 1

57. IP-Port 2 Empfänger-Instanz 1

58. Empfänger-Instanz 2

59. IP-Adresse 1 Empfänger-Instanz 2

60. IP-Port_1 Empfänger-Instanz 2

61 . IP-Adresse_2 Empfänger-Instanz 2

62. IP-Port 2 Empfänger-Instanz 2

63. Physikalische Firewall

64. Datendienst Firewall-Regel

65. DNS-basierter Loadbalancer

66. Datendienst DNS-basierte Loadbalancingregel 67. Root-Element

68. IT-Verfahrensgruppe 1 69. IT-Verfahren 1

70. Release 1 .1

71 . Release 1 .2

72. Installationsstrang A

73. Installationsstrang B

74. IT-Verfahrensgruppe 2

75. IT-Verfahren 2

76. IT-Verfahrensgruppe

77. IT-Verfahren, Label: IT-Verfahren, Name: IT-Verfahren

78. Release 1 , Label: Releasel , Name: IT-Verfahren_Release1

79. Release 2, Label: Release2, Name: IT-Verfahren_Release2

80. Betriebssystem-Instanz, Label: Serverl , Name: Serverl

81 . Middleware-Instanz Apache Webserver 2, Label: Apache2,

Name: Server1 _Apache2

82. Middleware-Instanz Apache Webserver 1 , Label: Apachel ,

Name: Server1 _Apache1

83. Betriebssystem-Instanz, Label: Serverl ,

Name: IT-Verfahren_Release1 _Server1

84. Betriebssystem-Instanz, Label: Serverl ,

Name: IT-Verfahren_Release2_Server1

85. Middleware-Instanz Apache Webserver 1 , Label: Apachel ,

Name: IT-Verfahren_Release1 _Server1 _Apache1

86. Middleware-Instanz Apache Webserver 1 , Label: Apachel ,

Name: IT-Verfahren_Release2_Server1 _Apache1

87. Middleware-I nstanz Apache Webserver 2, Label: Apache2,

Name: IT-Verfahren_Release2_Server1 _Apache2

88. Plattformgruppe

89. Unique-Element Physikalische Betriebssystem-Instanz X,

Label: Prod_Server_X, Name: Prod_Server_X

90. Release 1 .1 mit Attribut: Umgebung

91 . Neu zu erfassendes Middleware-Element

92. Vergleichswerte 3 {IT-Verfahren, 1 IT-Verfahren 1, IT- Verfahren 1, IT- Verfahren 1)

93. Vergleichswerte 2 {Umgebung Prod, Umgebung Prod, Umgebung Test, Um- gebung Prod,)

94. Vergleichswerte 1 {Server 1, Server 1, Server 1 , Server 2,) 95. Ergebnisspalte {Middleware-MW- 1 , Middleware-MW-2, Middleware-MW-3, Middleware-MW-4)

96. Betriebssystem-Instanz mit Attribut: Typ=Solaris 9

97. Betriebssystem-Instanz mit Attribut: Typ=Solaris 10

98. Relation wird in Release 2 gelöscht

99. Gruppe INet, wird in Release 2 gelöscht

100. Relation wird in Release 2 hinzugefügt

101 . Applikations-Instanz

102. Geschäftsprozess

103. IT-Verfahrensumgebung

104. Veritas-Cluster Betriebssystem-Instanz, Serverl 00c

105. IT-Verfahrens-Installationsbasis

106. Middleware

107. Server 1 (Server 1 00n)

108. Server 2 (Server 200n)

109. DNS-Datenverbindung

1 10. Globale Loadbalancing-Gruppe

1 1 1 . Lokaler Loadbalancer

1 12. I P-Adresse

1 1 3. I P-Port

1 14. Cluster

1 15. Clusterbasis 1

1 16. Clusterbasis 2

1 1 7. zu überwachendes Element, z.B. eine Webserverinstanz

1 18. Überwachungswerkzeug, z.B. Nagios

1 1 9. Überwachungsaufgabe l

120. Überwachungsaufgabe 2

121 . Überwachungsaufgabe 3

122. Server

123. End-to-End-Überwachungswerkzeug

124. Plan-Server 1 (#CPU, Speicher #GB, Servicelevel, ...)

125. Middleware 1

126. Plan-Server 2 (#CPU, Speicher #GB, Servicelevel, ...)

127. Applikation A

128. Geschäftsprozess G 1

129. Plan-Server 3 (#CPU, Speicher #GB, Servicelevel, ...) 130. Middleware 2

131 . Applikation B

132. Geschäftsprozess G2

133. Physischer Server 1

134. Physischer Server 2

135. GRP-Bereich, Kunde A-IT-Verfahren

136. GRP-IT-Verfahren, Kundenverfahren-A1

137. GRP-Umgebung Produktion

138. OSS-Server-virtuell, KVA 1 -206 v.linux.rz.db.de

139. Verfahrensinstallationsbasis Unix, Verfahrensumgebung

140. Middleware-Instanz Apache, Apache 1

141 . Middleware-Instanz JBOSS, JBOSS 1

142. Apl-Applikation, KVA 1 -JEE-Appl 1

143. NET-IP-Adresse des Servers, 172.17.75.86

144. NET-IP-Adresse des Apache Webservers, 172.17.75.87

145. IP-Verbindung vom Browser eines Clients aus

146. NET-Dienst - IP-Port, http; vom Apache angeboten

147. GRP-IP-Datenverbindung, abgehend

148. IP-Verbindung von Apache auf Weblogic, Sekundärrelation 149. GRP-Default-IP-Adresse Server

150. NET-Dienste, vom JBOSS-Server angeboten

151 . I P-Verbindung zu einer Datenbank

152. GRP-Bereich RZ-Produktion

153. GRP-IT-Plattform Unix-Server

154. OSS-Server, physisch, RZ1 -471 1 . Iinux.rz.db.de

155. NET-IP-Adresse 192.168.1 .186

156. NET-Dienst -IP-Port ssh

157. NET-IP-Adresse 192.170.1 .186

158. NET-Dienst - IP-Port backup

159. OSS-Endgerätegruppe, Internetclient

160. OSS-Server virtuell, DB-246v.linux.rz.db.de

161 . DAT-Oracle; Oracle-DB-KVA1

162. NET-IP-Adresse, 172.25.36.1 1

163. OSS-Server, physisch, RZ1 -4712.linux.rz.db.de

164. NET-Dienst IP-Port sql

165. OSS-Endgerätegruppe, Extranetclient 166. OSS-Server virtuell; KVA1207v.linux.rz.db.de

167. NET-I P-Adresse 172.17.75.88

168. Graphisches Frontend

169. Topologie-Datenbank

170. Strukturbaumdarstellung

171 . Strukturbaumanalyse

172. Analyseregeln: Angebotsdefinition

173. Analyseregeln: Assetdefinition

174. Analyseregeln: Qualitässicherung

175. Analyseregeln:Ermittlung, Reihung und Parametrisierung der Installationsaufgaben

176. Analyseregeln: Objektspezifisches Monitoring

177. Analyseregeln: Serviceorientiertes Monitoring

178. Analyseregeln: IT-Governance

179. Konverter; Ermittlung Artikelnummern

180. Assetverwaltung, Kapazitätsmanagement

181 . Komplexe Prüfroutinen

182. Workflow Ablaufplan

183. Objektspezifische Monitoringtools

184. Konverter; Strukturbaum-Invertierung

185. Enterprise Architektur Planung

186. Preisauskunft

187. Angebotserstellung Leistungsschein

188. Fachliche Verantwortliche; komplexe Prüfroutinen

189. Installationsskript-Executor; für jeden Elementtyp

190. Changemanagement

191 . Assetmanagement

192. Business Service Monitoring

193. Zuliefersysteme

194. Qualitätssicherung

195. Mandanten

1 96. Zielsysteme/Nutzer

1 97. Servicekatalog

198. UML-Darstellungen aus der Softwareentwicklung

199. Unterschiedserkennung zwischen Soll-Kaufm und Ist-Kaufm

200. Kaufmännische Qualitätssicherung QS Kaufm 201 . Ja-Zweig

202. Nein-Zweig

203. Verzweigungsabfrage: Fehler vorhanden?

204. Verzweigungsabfrage: Umsetzung beauftragt?

205. Verzweigungsabfrage: QS Kaufm erfolgreich?

206. Erkennung der Absolutwerte und der Unterschiede zwischen Soll Technisch und Ist Technisch

207. Technische Qualitätssicherung

208. Vorlagen

209. Kalkulations-Varianten

210. Kfm. Angebot

21 1 . Soll-Kaufm.

212. Ist-Kaufm

213. Planung

214. Releasemanagement VBF

215. Systemplanung

216. Warten und ggf. Planung anpassen

217. To-Be-Installed; Soll Technisch

218. Installed; Ist Technisch

219. Kaufmännische Analysemethode, Kfm

220. Analysemethode Systemplanung, SP

221 . Analysemethode Installation, Install

222. Analysemethode Monitoring, Mon

223. Analysemethode IT-Governance, Gov

224. Artikelnummern und Preisermittlung

225. Angebotsmanagement, Vertragsabschluss

226. Assetverwaltung, Capacitymanagement

227. Installationsagenten

228. Changemanagement

229. Abrechnungssystem, Billing

230. Business Service Monitoring

231 . Objektspezifische Monitoringsysteme

232. Enterprise Architektur Management

233. NET-DNS-Datenverbindung WWW.KVA1 .COM

234. NET-IP-Adresse 172.17.75.87

235. GRP-Bereich- Vorlagen; Servicekatalog 236. GRP-Vorlage-Linux; Apache auf Linux

237. OSS-Linux-Server-virtuell; Linux-Server

238. NET-IP-Adresse 172.x.y.z

239. Middlewareinstanz Apache; Apache

240. NET-IP-Adresse 172. a.b. c

241 . NET-Dienst-IP-Port; http Port 80

242. NET-Dienst-IP-Port; https Port 443

243. Smart Copy, mit Anpassung von IP-Adressen, Servernamen, Ports, etc.

244. IT-Verfahren; Kundenverfahren

245. Verfahrensumgebung Produktion

246. GRP-Vorlage-Linux; Apache auf Linux, eingefügt

247. OSS-Linux-Server-virtuell; KV-linux1 -v.linux.rz.db.de

248. NET-IP-Adresse 172.17.83.1 1

249. NET-IP-Adresse 172.17.75.87

250. NET-Dienst-IP-Port; http Port 8000

251 . NET-Dienst-IP-Port; https Port 443

252. GRP-Vorlage-Linux; Apache-auf-Linux-2,

253. OSS-Server-virtuell; z/OS Host

254. GRP-Bereich -Vorlagen; Technische Lösungen

255. GRP-Vorlage Windows; Information-Sevrer

256. OSS-Windows-Server-virtuell; WindowsServer

257. Verfahrensinstallationsbasis Windows; Verfahrensumgebung

258. Middleware-Informationsserver; Win-Webserver

259. Applikation APPL-Doku-Anwendung; Dokumentationssystem

260. GRP-Bereich-Vorlagen; Referenzarchitekturen

261 . GRP-Vorlage-RefArch; Web-Standard

262. frei

263. GRP-Vorlage-RefArch; Web-Standard; eingefügt

264. GRP-Vorlage-Linux; Apache auf Linux; eingefügt

265. OSS-Linux-Server-virtuell; KV-Linux.Linux. rz.db.de

266. NET-IP-Adresse 172.12.13.14

267. GRP-Vorlage-Windows; Information-Server; eingefügt

268. OSS-Windows-Server-virtuell; KV-Win.Windowsrz. db.de

269. NET-IP-Adresse 172.14.13.15

270. NET-IP-Adresse 172.15.13.16

271 . NET-Dienst-IP-Port; Http Port80 272. Middleware MW-sonstige; Spez-Doku-System; eingefügt

Claims

Patentansprüche

1 . Verfahren zur Gesamtbehandlung eines IT-Verfahrens mit kompletter Umgebung aus Clients, Servern, Middlewarekomponenten, Applikationen und Netzwerkkomponenten, die ein Endanwender zur Durchführung eines spezifischen IT-gestützten Geschäftsprozesses benötigt, wobei die erforderlichen Informationen zur Beschreibung der Topologie des IT-Verfahrens in mindestens einem Strukturbaum bereitgestellt werden, die

• zum Ermitteln der Installationsaufgaben und/oder

· zur automatischen Durchführung der Installation von IT-Komponenten und/oder

• zur Konfiguration und/oder Einrichtung von Monitoringsystemen zur Überwachung einzelner IT-Elemente und/oder

• zur Konfiguration und/oder Einrichtung von serviceorientierten Monito- ringsystemen und/oder

• zur Systemplanung und/oder

• zum Kapazitätsmanagement und/oder

• zur kaufmännischen Analyse und/oder

• zur kaufmännischen Qualitätssicherung und/oder

· zur technischen Qualitätssicherung und/oder

• zur Erstellung von Änderungsaufträgen an das Change-Management und/oder zur Rechnungserstellung und/oder

• zur Verwendung in einem Enterprise Architektur Management aufbereitet und weiterverarbeitet werden, wobei für den Strukturbaum eine Metastruktur verwendet wird, die generisch definiert, welche IT- Verfahrenselementtypen zulässig sind, welche Attribute zu den IT- Verfahrenselementtypen zugelassen und/oder erforderlich sind, welche Relationen zwischen den IT-Verfahrenselementtypen möglich sind, und welche Attri- bute zu den Relationen zugelassen und/oder erforderlich sind, wobei durch den Formalismus der Metastruktur nur eindeutige und schleifenfreie topologische Beziehungen zwischen den IT-Verfahrenselementen erlaubt werden, indem als Metastruktur ein azyklisch gerichteter Graph verwendet wird, der bei einem Wurzelelement startet und sich alle Kindelemente unter ihre jeweiligen Eltern- elemente ordnen, wobei die Kindelemente wiederum nur für solche Elemente Elternelemente sein dürfen, die nicht ihrerseits zu den Elternelementen dieser Kindelemente zählen.

2. Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß Anspruch 1 , wobei

Unique-Elemente in der Topologie der Metastruktur verwendet werden, deren Namen in der Topologie der Metastruktur genau einmal enthalten sind,

- Non-Unique-Elemente in der Topologie der Metastruktur verwendet werden, deren Eigennamen in der Topologie der Metastruktur mehr als einmal enthalten sind, deren Gesamtnamen aber dadurch eindeutig gekennzeichnet werden, dass ihr Gesamtname jeweils durch Verknüpfung des Eigennamens mit dem Namen des bei seiner Erzeugung übergeordneten Elternelements gebildet wird,

Primärrelationen zwischen Eltern- und Kindelementen definiert werden, wobei Kinder einer Primärrelation solange in der Topologie existieren, bis auch die letzte Primärrelation zu diesem Kind entfernt wird,

- Sekundärrelationen zwischen Eltern- und Kindelementen definiert werden, wobei

a. Sekundärrelationen nur zu bereits angelegten Kind-Elementen führen dürfen,

b. Sekundärrelationen nur dann zu Kindelementen verweisen dürfen, wenn das Kindelement über mindestens eine Primärrelation verfügt,

- von der Metastruktur jeweils nur entweder eine Primärrelation oder eine Sekundärrelation zwischen zwei Elementtypen erlaubt wird,

- zu jedem im Strukturbaum enthaltenen Element Attribute zugewiesen werden können,

- zu jeder im Strukturbaum enthaltenen Relation Attribute zugewiesen werden können.

3. Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß Anspruch 2, wobei Datenverbindungen in der Metastruktur als Sekundärrelationen modelliert werden, indem sie - zwischen jeweils einer Sender-Instanz und mindestens einer Empfänger- Instanz oder

- zwischen jeweils einer als eigenes Element identifizierbaren„benannten Datenverbindung", die Kindelement mehrerer Sender-Elternelemente sein kann und mindestens einer Empfänger-Instanz

angelegt werden.

4. Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß Anspruch 2 oder 3, wobei

a. Gruppierungselemente durch Unique- oder Non-Unique-Elemente modelliert werden,

b. für jede Gruppendarstellung ein eigener Zweig im Strukturbaum entsteht,

c. Elemente aus unterschiedlichen Gruppendarstellungen innerhalb des Strukturbaums durch Primär- und/oder Sekundärrelationen verknüpft werden dürfen.

5. Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß mindestens einem der zuvor genannten Ansprüche, wobei,

a. falls im Rahmen des Designs einer IT-Anwendung eine Software entwickelt wird, die Software mithilfe einer standardisierten Software- Modellierungssprache entwickelt wird, und die in der Software- Modellierung enthaltenen Informationen für die Erstellung der Grob- struktur des Strukturbaums als Kopiervorlage verwendet werden, und/ oder sonstige in einer standardisierten Modellierungssprache formulierte Referenzstrukturen und/oder technische Lösungen als Kopiervorlage verwendet werden,

b. im Rahmen der Angebotserstellung unter Verwendung der unter a de- finierten Struktur nur Leistungen angeboten werden, die in einem datenbankgestützten Servicekatalog enthalten sind, wobei im Angebot die kostenbestimmenden Faktoren Anzahl, Leistungsparameter und Typ der zu verwendenden Leistungselemente festgelegt werden, c. jedes beauftragte IT-Verfahren in der Metastruktur innerhalb einer IT- Verfahrensgruppe jeweils als einzelnes Release unter Verwendung von Non-Unique-Elementen angelegt wird, jede nutzbare Plattforminstanz in der Metastruktur innerhalb von mindestens einer IT-Plattformgruppe angelegt wird, und

anschließend allen Verfahrens-Elementen aus den in c) erstellten IT- Verfahrenszweigen mittels Sekundärrelationen jeweils genau eine konkrete Plattforminstanz aus d) zugewiesen wird.

Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß Anspruch 5, wobei für die manuelle Erfassung von Informationen Regulär Expressions definiert werden, die die Eingabemöglichkeiten beschränken.

Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß Anspruch 5 oder 6, wobei bei der manuellen Erfassung von aus einer großen Tabelle auswählbaren Werten für Eigennamen und/oder Attribute von Elementen, die Zahl der auswählbaren Werte dadurch eingeschränkt wird, dass alle im Pfad des Strukturbaums erfassten übergeordneten Informationen, die als Bedingungen für die Auswahl der Werte verwendet werden können, über eine UND-Verknüpfung miteinander zu einer Gesamtbedingung verbunden werden, und nur noch die Werte für die Erfassung zur Auswahl angeboten werden, die die Gesamtbedingung erfüllen.

Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß mindestens einem der Ansprüche 5 bis 7, wobei zur automatischen Erfassung von Informationen durch Einlesen von geeignet formatierten Massendatenstruktu- ren unterhalb eines eindeutigen Knotenelements alle Elemente, Attribute, Primär- und Sekundärrelationen importiert werden, dann die Relationen und Metatypen hinsichtlich ihrer Gültigkeit überprüft werden, und, falls diese als nicht gültig erkannt werden, entweder der ganze Importvorgang abgebrochen wird, oder, falls nur Sekundärrelationen betroffen sind, eine Fehlerliste erstellt wird, in der alle ungültigen Sekundärrelationen aufgeführt werden und anschließend vom Nutzer überprüft werden.

Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß mindestens einem der Ansprüche 5 bis 8, wobei sich eine bereits erfasste Teil-Struktur mit einer eigenen Kopierfunktion duplizieren und an einer anderen geeigneten Stelle des Strukturbaums einfügen lässt, und dabei alle Relationen innerhalb des duplizierten Teils erhalten bleiben,

lediglich die Eigennamen und Attribute der duplizierten Elemente nachträglich angepasst werden können, Elemente, die in dem duplizierten Teilbaum nur über Sekundärrelationen angebunden sind, nicht editiert werden können, vor dem Einfügen des kopierten Teilbaumes alle Metamodell- beziehungen auf ihre Gültigkeit geprüft werden und der Kopiervorgang physisch erst bei vollständiger Konformität zum Metamodell durchgeführt wird.

10. Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß mindestens einem der zuvor genannten Ansprüche, wobei im Verfahrens-Strukturbaum

- bei benannten Datenverbindungs-Elementen, die zu Elementen eines Clusters führen, Attribute angelegt werden, die Schwellwerte benennen, ab denen der Ausfall einer vom Schwellwert definierten Anzahl dieser Cluster-Elemente in einem serviceo- rienterten Monitoringprozess als kritisch bewertet wird,

- bei einzelnen Elementen, die für sich alleine überwacht werden sollen, die Überwachungswerkzeuge als Kind des zu überwachenden Elements angelegt werden und jede Überwachungsaufgabe jeweils als Kind des zugehörigen Überwachungswerkzeugs angelegt wird, wobei die einzelnen Überwachungsaufgaben jeweils eine maschinenlesbare Darstellung der Überwachungsaufgabe und die Beschreibung der dazugehörigen Handlungsanweisung und/oder Fehlerbehebungsskripte enthalten.

1 1 . Verfahren zur Gesamtbehandlung eines IT-Verfahrens gemäß mindestens einem der zuvor genannten Ansprüche, wobei im Verfahrens-Strukturbaum den Applikationen als Kindelemente Geschäftsprozesse des Anwenders zugeordnet werden, denen wiederum als Kindelemente ein oder mehrere aktive End-to-End-Überwachungswerkzeuge und/oder fachliche Monitoring- Systeme zugewiesen werden können, wobei sowohl den aktiven End-to-End- Überwachungswerkzeugen als auch den fachlichen Monitoringsystemen Überwachungsaufgaben und/oder Handlungsanweisungen zugewiesen werden können.

12. Verfahren zum Exportieren eines Teils eines Strukturbaums gemäß mindes- tens einem der zuvor genannten Ansprüche in ein Dateiformat, das die Darstellung hierarchisch strukturierter Daten unterstützt, dadurch gekennzeichnet, dass bei Elementen, die in der Metastruktur mit einem entsprechenden Attribut angelegt worden sind,

- ab dem Export-Startelement im Teilbaum alle bis zum Endpunkt- Element baumabwärts angelegten Elemente mit den zugehörigen Relationen exportiert werden und zusätzlich

- startend vom Endpunkt des Teilbaums auch alle baumaufwärts mit dem Endpunkt-Element entweder mit allen zugehörigen Relationen oder nur mit den zugehörigen Primärrelationen verknüpften Elemente exportiert werden.

13. Verfahren zum Planen und Umsetzen eines Upgrades für ein IT- Verfahren unter Verwendung von Strukturbäumen gemäß mindestens einem der zuvor genannten Ansprüche, dadurch gekennzeichnet, dass

a. der Strukturbaum des vorhandenen Releases in ein Dateiformat exportiert wird, das die Darstellung hierarchisch strukturierter Daten unterstützt,

b. der Strukturbaum des geplanten Releases erstellt und ebenfalls in ein Dateiformat exportiert wird, das die Darstellung hierarchisch struktu- rierter Daten unterstützt,

c. die in a) und b) erstellten Dateien von einer Datenverarbeitungsanlage verglichen werden und die Ergebnisse des Vergleichs in strukturierter Form ausgegeben werden, wobei erkennbar wird,

- ob ein Element beim Upgrade mit all seinen Attributen verändert wird,

- welche Elemente beim Upgrade gelöscht werden,

- welche Relationen beim Upgrade gelöscht werden,

- welche Elemente beim Upgrade ergänzt wurden,

- welche Relationen beim Update hinzugefügt wurden. ^. Maschinenlesbares Speichermedium mit maschinenauslesbaren Steuersignalen, die so mit einem programmierbaren Computersystem zusammenwirken können, dass ein Verfahren nach mindestens einem der Ansprüche 1 bis 13 ausgeführt wird.

1 5. Computer-Programm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode zum Ausführen eines Verfahrens gemäß mindestens einem der Ansprüche 1 bis 13, wenn das Programm-Produkt auf einem Computer ausgeführt wird.