DE102010007967A1 - Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens - Google Patents

Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens Download PDF

Info

Publication number
DE102010007967A1
DE102010007967A1 DE102010007967A DE102010007967A DE102010007967A1 DE 102010007967 A1 DE102010007967 A1 DE 102010007967A1 DE 102010007967 A DE102010007967 A DE 102010007967A DE 102010007967 A DE102010007967 A DE 102010007967A DE 102010007967 A1 DE102010007967 A1 DE 102010007967A1
Authority
DE
Germany
Prior art keywords
elements
tree
server
child
relations
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102010007967A
Other languages
English (en)
Inventor
Klaus Dr. 55128 Bermuth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
DB Systel GmbH
Original Assignee
DB Systel GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by DB Systel GmbH filed Critical DB Systel GmbH
Priority to DE102010007967A priority Critical patent/DE102010007967A1/de
Priority to CA2789393A priority patent/CA2789393A1/en
Priority to PCT/EP2011/000501 priority patent/WO2011098231A2/de
Priority to EP11702941A priority patent/EP2537126A2/de
Priority to US13/577,726 priority patent/US20120317050A1/en
Publication of DE102010007967A1 publication Critical patent/DE102010007967A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

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

  • 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 eines 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 Überwachungsaufgaben 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 Reihenfolge 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 Redeaper „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ätze 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 zwischen 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 Bezeichner 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 Middlewarekomponenten 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 „Server” des Labels des Elements „Server4711”) + Netzbereich der public-IP-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 Elemenen der IT-Verfahrenstechnik und den zugrunde liegenden Plattform-Elementen, die gewöhnlich unterschiedlichen Verantwortungsbereichen zugeordnet 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 unterstü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 derart, 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äß Patentanspruch 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 1 bis 28 die Zusammenhänge in Diagrammen dargestellt.
  • 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.
  • 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.
  • 3 geht aus 2 hervor und zeigt eine Darstellung einer Referenz (10) auf ein Element (9).
  • 4 zeigt eine Darstellung von Primär- und Sekundärrelationen. Bei Sekundä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 Primarrelation (16), die dicke Linie die Sekundärrelation (13).
  • 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).
  • 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 Empfänger-Instanz existiert.
  • 7 ist abgeleitet aus 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.
  • 8 ist abgeleitet aus 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.
  • 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 benannten Datenverbindung (42) angelegt und über Sekundärrelationen (13) mit den Elementen der zugehörigen physischen Komponenten (63, 65) verknüpft.
  • 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örenden Installationsstränge A (72) und B (73) sind hier sechseckig dargestellt.
  • 11 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 Release 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 11 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) gehört.
  • 12 zeigt die erfindungsgemäße Kombinationslösung des in der Beschreibung zur 11 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.
  • 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.
  • 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.
  • 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 „Solaris10” im Element Server (96, 97).
  • 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 (IP-Port, 39) verknüpft. Innerhalb der Definition der Mets-Relation zu Relation (13) wird einmalig für alle diese speziellen Metarelationen festgelegt, dass der Export des Baumes vom Kindelement (hier IP-Port, 39) aus die baumaufwärtsgerichtete Spiegelung enthält. Deshalb wird auch der baumaufwärts gerichtete Teilstrukturbaum bis zur Empfängerinstanz (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.
  • 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 Monitoring (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).
  • 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 (104) 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 logische, 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 19 zeigt die beispielhafte Darstellung eines Clusters vom Typ b. Der Datensender (Sender-Instanz1, 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.13.15 (59) als Ziel zurück. Damit werden abwechselnd die Empfänger-Instanzen 1 (53) und 2 (58) angesprochen.
  • Die 20 zeigt, wie die Beispielcluster aus den 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), (110), (111) für das Monitoring übersetzt in das Elternelement „Cluster” (114). Die Instanzen zu diesen Clusterelementen (115)/(116) sind dann die Elemente (107)/(108), bzw. (53)/(58). Während beim Betriebssystemcluster diese Information aus dem Installations-Strukturbaum sofort ableitbar ist, muss bei den beiden anderen Loadbalancingtypen diese Information durch Auswertung der Datenverbindungen (109) bzw. (36) indirekt ermittelt werden.
  • Die 21 zeigt die Modellierung einer elementspezifischen Überwachung am Beispiel eines Webservers (117).
  • Die 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 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 Zuweisung zu den exakten physischen Instanzen (133, 134).
  • Die 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-4711.linux, 154) zugewiesen.
  • Die 25 zeigt das IT-Verfahren aus 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 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 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 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 (194) genannt. Der Strukturbaum selbst wird in verschiedenen Mandanten (195) gehalten, die Basis für den Erfassungsprozess bzw. den Installationsprozess sind. Die kreisrunden Elemente (219 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 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.
  • 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 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 Apache1 (140) im IT-Verfahren ersetzt durch 172.17.75.87 (249). Ebenso können im Rahmen des Kopiervorgangs auch Attribute verändert werden.
  • 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 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 Linux (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 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 Modellierung 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 generischen 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 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.
  • 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. 1). Da schon beim Anlegen der Elemente durch den Formalismus der Metastruktur verhindert wird, dass einem Elternelement Kindelemente zugeordnet 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 Strukturierung 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. Beispielsweise lässt sich eine Datenbank für ein IT-Verfahren über einfache Kommandos wie CREATE TABLE, INSERT, ... aufbauen. Die 500 Spezialparameter zur Konfiguration der Datenbank sind dabei während der Erstinstallation unerheblich.
  • 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 Metamodell getroffen. Unique-Elemente (6, 7) sind solche, deren Eigenname (im allgemeinen bestehend aus Elementtyp und Elementname) im Rahmen der Topologie 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. 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 (11) über Sekundärrelationen (13) zugewiesen werden. Das bedeutet, dass Sekundärrelationen nur zu bereits im Metamodell angelegten Elementen führen dürfen (s. 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 Element 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 erlaubt. 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 Hilfe 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. 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. 7).
  • Speziell bei DNS-Verbindungen werden mehrere Sender (43, 48) zusammengefasst, indem zu der benannten Datenverbindung (42) mehrere Elternobjekte (36) zugelassen werden (s. 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 Datenverbindung 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. 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 strukturiert werden, indem Gruppierungen von Elementen angelegt werden (s. 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. Solche 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 unterschiedlichen Releases hinweg (s. 11).
  • In Anspruch 5 ist beschrieben, wie die in 13 dargestellten, zur Erstellung des Strukturbaums erforderlichen Informationen vorteilhaft erfasst und verwendet werden.
  • An der Bereitstellung eines IT-Verfahrens sind vom Vertrieb, über Servicemanagement, 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.
    • 2. 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 Leistungselemente 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 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.
    • 3. 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 anderen 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.
    • 4. Jetzt werden all denjenigen IT-Verfahrenselementen aus dem Verfahrensbaum konkrete Plattforminstanzen, also z. B. Betriebssysteminstanzen, Server, Message Queuemanager, etc. in der Gruppierung des Plattformbaums 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 IP-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, Regular 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. 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 angeboten 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 mindestens 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 werden, 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 ausgeschnittenen 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 vorteilhaft 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 mehrere 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 (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 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 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 primäre Server-100n (107) aus, so übernimmt nach kurzer Übernahmezeit der sekundäre Server-200n (108) die Bereitstellung der Betriebssysteminstanz Server-100c (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ärrelationen (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 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 Clustervarianten 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 (110) und lokales Loadbalancing (111 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 einige 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 (111)) als Attribut mitgegeben, s. 20.
  • Für das objektspezifische Monitoring von einzelnen Elementen (117) (z. B. Betriebssysteminstanzen, Middleware- oder Datenbankeninstanzen, ...., jedes überwachbare Objekt) besteht die Möglichkeit im Strukturbaum zu definieren, mit welchem Monitoring-Werkzeug (118) diese überwacht werden und ggf. mit welchen Überwachungsaufgaben/-Skripten (119, 120, 121). Dies ist in 21 dargestellt.
  • In einigen speziellen Fällen ist es sinnvoll, dass mehrere verschiedene Überwachungswerkzeuge ein Element überwachen. Daher wird hier das Überwachungswerkzeug (118) als Kindelement des überwachten Elements (117) 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” (119, 120, 121) umfassen jeweils eine maschinenlesbare Darstellung der Überwachungsaufgabe und die Beschreibung der dazugehörigen Handlungsanweisung bzw. das dazugehörige Fehlerbehebungsskript. Auf diese Weise hat man in den Strukturbaum direkt eine Monitoring-Event-Datenbank integriert, die insbesondere für die IT-verfahrensspezifischen Überwachungen sehr hilfreich ist.
  • Anspruch 11 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 Unternehmers 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 Applikationsteile 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 22. Sowohl den aktiven End-to-End-Überwachungswerkzeugen (123) als auch den fachlichen Monitoringsystemen können Überwachungsaufgaben und Handlungsanweisungen bzw. Lösungsskripte (119, 120, 121) zugewiesen werden.
  • In Anspruch 12 ist ein Verfahren beschrieben, mit dem Teile eines Strukturbaums in ein Datenformat exportiert werden können, das die Darstellung hierarchisch 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 Managementsystemen, 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 Metaelementtyps (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 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 Upgrades 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 ebenfalls 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. 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 Vergleich 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 Verfahrens 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 werden die in einem Strukturbaum eines IT-Verfahrens enthaltenen Informationen 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 zusammengefasst werden können.
  • Zu unterscheiden sind dabei generell die 4 Schritte:
    • 1. IT-Verfahrensbeschreibung (in Baumdarstellung oder graphisch als generisch 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 Schnittstellen der Zielsysteme
    • 4. Nutzung der Daten durch die Zielsysteme
  • Einen Überblick über die Zielsysteme liefert 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 gesteuert 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 Assetmanagement 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 mengenmäßig verwaltet werden. Das Assetmanagement verwendet aus dem Strukturbaum (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) enthaltenen Informationen zugegriffen, um die Installationsaufgaben zu ermitteln, sie in eine passende Reihenfolge zu bringen (182) und geeignet zu parametrisieren (175).
  • Die eigentliche Installation kann durch eine Workflowkomponente (182) überwacht 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, maschinell 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 Datenbeziehungen zwischen verschiedenen IT-Verfahren bereitgestellt werden können. Dies unterstützt den Abgleich gegen fachlich bekannte Datenbeziehungen zwischen den IT-Verfahren.
  • Gemäß Anspruch 15 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 programmierbaren Computersystem zusammenzuwirken, dass das Computersystem mindestens eines der in den Ansprüchen 1 bis 14 genannten Verfahren ausführt.
  • Gemäß Anspruch 16 wird ein Computer-Programm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode erstellt. Dieses Computer-Programm-Produkt kann auf einem Computer laufen, so dass mindestens eines der in den Ansprüchen 1 bis 14 genannten Verfahren auf dem Computer ausgeführt wird.
  • Die Erfindung wird im Folgenden anhand von Ausführungsbeispielen näher er
  • lä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 maschinenlesbar 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 IP-Adressen (19, 21) erreichbar sein oder mehrere IP-Dienste (20), (22) anbieten (s. 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. 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ügbarkeit 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 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 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 29 nicht dargestellten JBOSS und allen datentechnischen Konnektivitäten (240, 241, 242, 147, wiederum ohne JBOSS-Komponenten). 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 der Middlewareserver.
  • Die Vorlage wird dann mittels des Smart Copy-Mechanismus (243) in die IT-Verfahrensbeschreibungen (rechts in 29) übertragen.
  • sHierbei 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 24. Bei dem Kopiervorgang werden einige der Vorgabewerte manuell ersetzt, z. B. wird die IP-Adresse 172.x.y.z des Apache-Servers ersetzt durch 172.17.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 29 gezeigten Beispiel wurde z. B. als Metaelementtyp für die Kopiervorlage „GRP-Vorlage-Linux; Apache-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 Einsatz 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 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 erfindungsgemäß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 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 Sekundä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 IP-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 UserID
    • • 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äß 28 dann der kaufmännischen Analysemethode (Kfm, 219) übergeben, die aus diesen Angaben die benötigten Artikelnummern des Servicekatalogs (197) 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” (211) ü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 IP-Adresse werden Strukturinformationen ausgewertet, wie z. B. ob die IP-Adresse zu einem Server in der Produktions- oder Abnahmeumgebung gehört, in welchem Sicherheitsbereich die IP-Adresse benötigt wird und weiche 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 geprü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 kurzfristig 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 zugewiesene 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 Anwendung 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” (217) ü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 „Install” (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 Changemanagement (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 miteinander 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 25 dargestellt.
  • Die Endgeräte werden nicht einzeln modelliert. Damit aber Firewall-Regeln automatisiert 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 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.kva1.com. Der DNS-Dienst löst diese Adresse auf und gibt als Zieladresse wechselweise die IP-Adressen und Ports der beiden Webserver aus (d. h. 172.17.75.87 (234) oder 172.17.75.88 (166) mit Port 80). 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.kva1.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 (137). Genutzt wird diese DNS-Adresse, indem sie als sekundäres Kind einer oder mehrerer Datenverbindungen 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ätzliche Attribute oder Verknüpfungen ausgedrückt werden, dass der Apache2 (81) nur im Release 2 (79) gültig ist (s. 11).
  • Modelliert man den Server non-unique, so kann man bereits über den Strukturbaum ausdrücken, dass im Release 1 (78) Apache1 (85) und im Release 2 (79) Apache1 (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 Apache1 und Apache2 in den beiden Releases auf dem physisch gleichen Server laufen, wird der Server zweimal modelliert: Im sogenannten Verfahrensbaum (links in 12, unterhalb der Verfahrensgruppe (76)) wird er non-unique modelliert (83 bzw. 84). Im Plattformbaum (rechts in 12, unterhalb der Plattformgruppe (88)) wird er unique modelliert (89). Über eine Sekundärrelation (13) wird jeweils der Bezug zwischen diesen Serverbeschreibungen hergestellt, s. 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 Installationsparameter 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 verwendeten 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 29 und 30 auf die Verwendung von Vorlagen für die Modellierung häufig verwendeter IT-Verfahrensteile näher eingegangen werden.
  • In 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.
  • 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 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 Apache1 (140) im IT-Verfahren ersetzt durch 172.17.75.87 (249).
  • Ebenso können im Rahmen des Kopiervorgangs auch Attribute verändert werden.
  • 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 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 Linux (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 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 = ElementB, Name = ElementB
    7
    Unique-Element, Label = ElementA, Name = ElementA
    8
    Non-Unique-Element, Label = ElementC, Name = ElementB_ElementC
    9
    Non-Unique-Element, Label = ElementD, Name = ElementB_ElementC_ElementD
    10
    Referenz
    11
    Elementtyp U, Label = ElementA
    12
    Elementtyp V, Label = ElementB
    13
    zulässige Sekundärrelation
    14
    unzulässige Sekundärrelation
    15a
    Elementtyp W, Label = ElementE
    15b
    Elementtyp W, Label = ElementD
    16
    Primärrelation
    17
    IT-Verfahren
    18
    Betriebssystem-Instanz (BI)
    19
    IP-Adresse BI
    20
    IP-Port BI
    21
    IP-Adresse BI backup
    22
    IP-Port BI 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-Instanz 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-Instanz 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: Release1, Name: IT-Verfahren_Release1
    79
    Release 2, Label: Release2, Name: IT-Verfahren_Release2
    80
    Betriebssystem-Instanz, Label: Server1, Name: Server1
    81
    Middleware-Instanz Apache Webserver 2, Label: Apache2, Name: Server1_Apache2
    82
    Middleware-Instanz Apache Webserver 1, Label: Apache1, Name: Server1_Apache1
    83
    Betriebssystem-Instanz, Label: Server1, Name: IT-Verfahren_Release1_Server1
    84
    Betriebssystem-Instanz, Label: Server1, Name: IT-Verfahren_Release2_Server1
    85
    Middleware-Instanz Apache Webserver 1, Label: Apache1, Name: IT-Verfahren_Release1_Server1_Apache1
    86
    Middleware-Instanz Apache Webserver 1, Label: Apache1, Name: IT-Verfahren_Release2_Server1_Apache1
    87
    Middleware-Instanz 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, Umgebung 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, Server100c
    105
    IT-Verfahrens-Installationsbasis
    106
    Middleware
    107
    Server 1 (Server 100n)
    108
    Server 2 (Server 200n)
    109
    DNS-Datenverbindung
    110
    Globale Loadbalancing-Gruppe
    111
    Lokaler Loadbalancer
    112
    IP-Adresse
    113
    IP-Port
    114
    Cluster
    115
    Clusterbasis 1
    116
    Clusterbasis 2
    117
    zu überwachendes Element, z. B. eine Webserverinstanz
    118
    Überwachungswerkzeug, z. B. Nagios
    119
    Überwachungsaufgabe 1
    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 G1
    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-206v.linux.rz.db.de
    139
    Verfahrensinstallationsbasis Unix, Verfahrensumgebung
    140
    Middleware-Instanz Apache, Apache 1
    141
    Middleware-Instanz JBOSS, JBOSS 1
    142
    ApI-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
    IP-Verbindung zu einer Datenbank
    152
    GRP-Bereich RZ-Produktion
    153
    GRP-IT-Plattform Unix-Server
    154
    OSS-Server, physisch, RZ1-4711.linux.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.11
    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-IP-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
    196
    Zielsysteme/Nutzer
    197
    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
    211
    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.11
    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 (16)

  1. Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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, dadurch gekennzeichnet, dass zur Beschreibung der Topologie der IT-Verfahrenselemente eine Metastruktur verwendet wird, die 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 Attribute 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 Elternelemente 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 generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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 generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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ängerinstanz 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 generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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 generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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 Grobstruktur 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 definierten 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, d. jede nutzbare Plattforminstanz in der Metastruktur innerhalb von mindestens einer IT-Plattformgruppe angelegt wird, und e. anschließend allen Verfahrens-Elementen aus den in c) erstellten IT-Verfahrenszweigen mittels Sekundärrelationen jeweils genau eine konkrete Plattforminstanz aus d) zugewiesen wird.
  6. Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie eines IT-Verfahrens gemäß Anspruch 5, wobei für die manuelle Erfassung von Informationen Regular Expressions definiert werden, die die Eingabemöglichkeiten beschränken.
  7. Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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.
  8. Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie eines IT-Verfahrens gemäß mindestens einem der Ansprüche 5 bis 7, wobei zur automatischen Erfassung von Informationen durch Einlesen von geeignet formatierten Massendatenstrukturen 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.
  9. Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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 Metamodellbeziehungen 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 generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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 serviceorienterten 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.
  11. Verfahren zur generischen Erstellung eines Strukturbaums zur Beschreibung der Topologie 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 Monitoringsysteme 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äß mindestens 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 strukturierter 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.
  14. Verfahren zur Gesamtbehandlung eines IT-Verfahrens, wobei die in mindestens einem Strukturbaum gemäß mindestens einem der zuvor genannten Ansprüche enthaltenen Informationen bereitgestellt, aufbereitet und weiterverarbeitet werden zur kaufmännischen Analyse und/oder zur Systemplanung und/oder zum Kapazitätsmanagement und/oder zur kaufmännischen Qualitätssicherung und/oder zur technischen Qualitätssicherung und/oder zum Ermitteln der Installationsaufgaben und/oder zur automatischen Durchführung der Installation von IT-Komponenten und/oder zur Erstellung von Änderungsaufträgen an das Change-Management und/oder zur Rechnungserstellung und/oder zur Konfiguration und/oder Einrichtung von Monitoringsystemen zur Überwachung einzelner IT-Elemente und/oder zur Konfiguration und/oder Einrichtung von serviceorientierten Monitoringsystemen und/oder zur Verwendung in einem Enterprise Architektur Management.
  15. 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 14 ausgeführt wird.
  16. Computer-Programm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode zum Ausführen eines Verfahrens gemäß mindestens einem der Ansprüche 1 bis 14, wenn das Programm-Produkt auf einem Computer ausgeführt wird.
DE102010007967A 2010-02-15 2010-02-15 Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens Ceased DE102010007967A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102010007967A DE102010007967A1 (de) 2010-02-15 2010-02-15 Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens
CA2789393A CA2789393A1 (en) 2010-02-15 2011-02-03 Method, computer program product and computer-readable storage medium for the generic creation of a structure tree for describing an it process
PCT/EP2011/000501 WO2011098231A2 (de) 2010-02-15 2011-02-03 Verfahren, computerprogram-produkt sowie computerlesbares speichermedium zur generischen erstellung eines strukturbaums zur beschreibung eines it-verfahrens
EP11702941A EP2537126A2 (de) 2010-02-15 2011-02-03 Verfahren, computerprogram-produkt sowie computerlesbares speichermedium zur generischen erstellung eines strukturbaums zur beschreibung eines it-verfahrens
US13/577,726 US20120317050A1 (en) 2010-02-15 2011-02-03 Method, computer program product and computer-readable storage medium for the generic creation of a structure tree for describing an it process

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102010007967A DE102010007967A1 (de) 2010-02-15 2010-02-15 Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens

Publications (1)

Publication Number Publication Date
DE102010007967A1 true DE102010007967A1 (de) 2011-08-18

Family

ID=43857726

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102010007967A Ceased DE102010007967A1 (de) 2010-02-15 2010-02-15 Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens

Country Status (5)

Country Link
US (1) US20120317050A1 (de)
EP (1) EP2537126A2 (de)
CA (1) CA2789393A1 (de)
DE (1) DE102010007967A1 (de)
WO (1) WO2011098231A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE202013003793U1 (de) 2013-04-23 2013-05-08 Db Systel Gmbh Datenträger mit darauf gespeicherten Daten sowie eine Daten repräsentierende Signalfolge zur Gewährleistung der Funktionsfähigkeit eines technischen Systems im Hinblick auf dessen Konfiguration im Rahmen einer Installation bzw. Beseitigung von Komponenten
DE102013006949A1 (de) 2013-04-23 2014-10-23 Db Systel Gmbh Verfahren zur Gewährleistung der Funktionsfähigkeit eines technischen Systems im Hinblick auf dessen Konfiguration im Rahmen einer Installation bzw. Beseitigung von Komponenten

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10585766B2 (en) * 2011-06-06 2020-03-10 Microsoft Technology Licensing, Llc Automatic configuration of a recovery service
US11074529B2 (en) 2015-12-04 2021-07-27 International Business Machines Corporation Predicting event types and time intervals for projects
US11120460B2 (en) 2015-12-21 2021-09-14 International Business Machines Corporation Effectiveness of service complexity configurations in top-down complex services design
US10902446B2 (en) 2016-06-24 2021-01-26 International Business Machines Corporation Top-down pricing of a complex service deal
US10248974B2 (en) 2016-06-24 2019-04-02 International Business Machines Corporation Assessing probability of winning an in-flight deal for different price points
US10929872B2 (en) 2016-06-24 2021-02-23 International Business Machines Corporation Augmenting missing values in historical or market data for deals
US10673787B2 (en) * 2017-10-03 2020-06-02 Servicenow, Inc. Virtual agent conversation service
US10755324B2 (en) 2018-01-02 2020-08-25 International Business Machines Corporation Selecting peer deals for information technology (IT) service deals
US11182833B2 (en) 2018-01-02 2021-11-23 International Business Machines Corporation Estimating annual cost reduction when pricing information technology (IT) service deals
CN110955551B (zh) * 2019-11-26 2023-05-26 上海新炬网络技术有限公司 一种基于tomcat中间件的故障智能诊断装置
CN112860850B (zh) * 2021-01-21 2022-08-30 平安科技（深圳）有限公司 人机交互方法、装置、设备及存储介质
US20230057746A1 (en) * 2021-08-21 2023-02-23 UiPath, Inc. User constrained process mining
CN113673966B (zh) * 2021-09-03 2024-03-08 卡奥斯数字科技(青岛)有限公司 信息安全建设方案生成方法、装置、电子设备及存储介质
CN115187181B (zh) * 2022-09-14 2023-08-08 深圳星网信通科技股份有限公司 物资管理方法、服务器及其存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7926051B2 (en) * 2003-11-10 2011-04-12 International Business Machines Corporation Automatic parallel non-dependent component deployment
WO2005050437A2 (de) * 2003-11-21 2005-06-02 Peter Neswal Verfahren zur installation und konfiguration von softwarekomponenten
US20070220509A1 (en) * 2006-02-24 2007-09-20 International Business Machines Corporation System and method for deploying software based on matching provisioning requirements and capabilities
US7606817B2 (en) * 2006-08-02 2009-10-20 Entity Labs, Ltd. Primenet data management system
US20090172674A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Managing the computer collection of information in an information technology environment
US20090171731A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Use of graphs in managing computing environments
US8880682B2 (en) * 2009-10-06 2014-11-04 Emc Corporation Integrated forensics platform for analyzing IT resources consumed to derive operational and architectural recommendations
US8743121B2 (en) * 2009-12-23 2014-06-03 Bmc Software, Inc. Smart impact views
US8539018B2 (en) * 2010-11-04 2013-09-17 International Business Machines Corporation Analysis of IT resource performance to business organization

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE202013003793U1 (de) 2013-04-23 2013-05-08 Db Systel Gmbh Datenträger mit darauf gespeicherten Daten sowie eine Daten repräsentierende Signalfolge zur Gewährleistung der Funktionsfähigkeit eines technischen Systems im Hinblick auf dessen Konfiguration im Rahmen einer Installation bzw. Beseitigung von Komponenten
DE102013006949A1 (de) 2013-04-23 2014-10-23 Db Systel Gmbh Verfahren zur Gewährleistung der Funktionsfähigkeit eines technischen Systems im Hinblick auf dessen Konfiguration im Rahmen einer Installation bzw. Beseitigung von Komponenten

Also Published As

Publication number Publication date
CA2789393A1 (en) 2011-08-18
US20120317050A1 (en) 2012-12-13
EP2537126A2 (de) 2012-12-26
WO2011098231A9 (de) 2013-02-07
WO2011098231A2 (de) 2011-08-18

Similar Documents

Publication Publication Date Title
DE102010007967A1 (de) Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens
KR101891506B1 (ko) 하나 이상의 클라우드 시스템 상에 애플리케이션들을 이식 가능하게 배치하기 위한 방법들 및 시스템들
US7941398B2 (en) Autopropagation of business intelligence metadata
DE60133648T2 (de) System und verfahren zum führen von laufzeitdaten in einem server-netzwerk
DE60009489T2 (de) Vorrichtung und verfahren zum verwalten der verteilung von inhalten zu einem gerät
DE112017006164T5 (de) Differenzvergleich von ausführbaren Datenflussdiagrammen
DE112010003144T5 (de) Erweiterbare Grundstruktur zur Unterstützung verschiedener Einsatzarchitekturen
DE112011105186T5 (de) Graphdatenbanken zum Speichern mehrdimensionaler Modelle von Software-Angeboten
DE102006023974B4 (de) System und Verfahren für maßgeschneiderte Anwendungsbestellung und Installation für Informationsverarbeitungssysteme
DE112020004623T5 (de) Ml-basierte ereignishandhabung
CN116055283B (zh) 支持全局设置租户应用资源配额的多平台统一云管系统
DE112011103522T5 (de) Erstellung eines Multidimensionalen Modells von Software-Angeboten
US11941068B2 (en) Case leaf nodes pointing to business objects or document types
DE112011102243T5 (de) Konfigurieren eines Computersystems für die Installation von Softwarepaketen
DE102021130957A1 (de) Empfehlungen zur stabilität von software-aktualisierungen
CN108052358A (zh) 一种分布式部署的系统和方法
DE69733918T2 (de) Verfahren und Vorrichtung zum Betrieb eines Benutzerkomputers ohne Anbietersoftware
DE112016005867T5 (de) Live-Pipeline-Vorlagen - Erstellung und Erweiterbarkeit der Vorlagen
DE102012210064A1 (de) Verwalten von aus Geschäftsobjekten erzeugten Ereignissen
EP2620868A1 (de) Arbeitsfluss-Management-System für Computernetze
US11544294B2 (en) Distributing tables in a distributed database using consolidated grouping sources
WO2017021186A1 (en) A computerized database management system
WO2014173505A1 (de) Verfahren zur gewährleistung der funktionsfähigkeit eines technischen systems im hinblick auf dessen konfiguration im rahmen einer installation bzw. beseitigung von komponenten
DE102020125869A1 (de) Verfahren und Vorrichtung zur Konfiguration eines Informationsverarbeitungssystems, Verfahren und Vorrichtung zur Verwaltung eines Dienstes, Computerprogramm und nichtflüchtiges Speichermedium
DE202019106136U1 (de) System zur Ausführung eines Identity und Access Managements

Legal Events

Date Code Title Description
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R003 Refusal decision now final
R008 Case pending at federal patent court
R003 Refusal decision now final
R011 All appeals rejected, refused or otherwise settled