EP2537126A2

EP2537126A2 - Method, computer program product and computer-readable storage medium for the generic creation of a tree structure for describing an it method

Info

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

Abstract

The invention relates to a method, to a computer program product and to a computer-readable storage medium for the generic creation of a tree structure for describing an IT method, comprising a complete environment composed of clients, servers, middleware components, applications and network components which an end user requires for carrying out a specific IT-supported business process. The invention is based on the generic creation of a tree structure for describing the topology of an IT method, by which tree structure it is possible to collect and manage all the data necessary for the overall handling of an IT method in a defined structure, such that all the procedures relevant for managing an IT method come from one data source and can be automated. The freedom from loops and the unambiguity of the elements result in a structuring of the data contained in the IT method, whereby automated processing is facilitated. A meta element type in the meta model is assigned to each of the elements used in the tree structure. The meta model describes which element types are allowed. The element types comprise all common generic IT components, such as server, middleware, storage, and the like. It is also established which attributes relating to the element types are allowed and/or necessary and which relations with the associated attributes are allowed between the elements. The freedom from loops is achieved by the use of an acyclically directed graph as the metastructure.

Description

The invention relates to a method, a computer program product and a computer-readable storage medium for the generic creation of a structure tree for describing an IT process with a complete environment of clients, computer program product and computer-readable storage medium for generically creating a structure tree. Servers, middleware components, applications and network components that an end user needs to complete a specific IT-enabled business process.

An IT process is the completely installed, interconnected, and possibly activated environment, consisting of clients, servers, middleware components, applications, and network components that an end user needs to complete a specific, IT-enabled business process.

In its entirety, the invention provides an overall treatment of an IT process. This concerns

- the automated installation of the IT process

- the company-wide architecture control,

- the conclusion or modification of service agreements for IT processes / IT services with end customers,

the technical installation of an IT process,

- reporting on the availability of an IT process and its elements,

the service-oriented monitoring and incident management of IT procedures including the assignment of fault messages to the originator of a fault,

the definition and documentation of object-specific monitoring tasks in the context of an IT procedure.

The management of IT processes requires, in various respects, more or less detailed information about the technical interaction of the elements.

There are a number of applications that help users get and manage such information. Although the required relationships always describe an identical environment, these different viewing angles are modeled separately from each other in the prior art.

For example, the description for the IT process installation follows the sequence Root Node - IT Method - Server - Middleware - Application. For an IT procedure, the servers are first installed. Then the middleware, e.g. a JEE application server is installed, and then the actual customer-specific application is installed on it.

In service-oriented monitoring, the description is different. Here you follow the sequence root node IT procedure - application - middleware - server. In this description, the end-to-end view of the user is expressed. An IT procedure is disturbed if the customer-specific application is disturbed. The application can not work if the middleware has a problem. And the middleware can not work if the underlying server is down.

When concluding benefit agreements / service contracts with the end customer, fine-grained relationships in and between the IT processes play a subordinate role. In this view, however, the quantities of services to be provided and also the qualities of service are relevant,

that affect the IT process operation. To plan it correctly, you need information about the structure of the IT process and the qualities required for each element, such as performance levels, service levels, etc. Thus, we have already developed Common Data Model (CDM) information models that attempt to make consistent definitions for the IT components, business systems and processes to be managed, taking into account the relationships between the elements (see, for example, the IBM Tivoli Common Data Model: Guide to Best Practices Redpaper).

A CDM essentially consists of data definitions that are organized in a logical model and stored in a predefined way in a database. This allows resource instances to be identified and information about the instances and their relationships to each other managed.

Business and infrastructure processes can be related to the IT systems that deliver the service based on the CDM. The data For example, they are grouped into groups that are subdivided into physical units, network, administration, storage, etc. The organization takes place hierarchically through object classes and their instances. The hierarchy starts with a root element that contains the abstract classes from which the logical and physical classes are derived. Subclasses inherit the abstract properties of their parent parent classes. The instances of the classes ultimately represent the resources. The instances are assigned attributes that are specified for the associated class. Instances can still have relationships with each other. Any relationship between two resource instances obeys given definitions, depending on the nature of the relationship. In general, there can be many different relationships between the same classes and their instances.

Each instance represented in a CDM has a name and a label associated with it, and each name is assigned a unique name using specific naming rules.

Disadvantages of such a classic, database-oriented design, are that there are very different description structures for each element type. The element descriptions must be very detailed in order to obtain from a detailed detailed description of the elements management methods, such as e.g. Support installation procedures.

It is imperative to include information that can be implied or calculated in modeling. So many details, such as the standard file systems are modeled by middleware components, although they can not be modified from the point of view of the IT process.

Thus, e.g. a technical server name is formed by linking the following information:

IT-procedure name + environment name + indicator "used in the cluster yes / no" + consecutive number (obtained from the splitting off of the prefix "server" of the label of the element "server 471 1") + network area of the public-I P-

Address (child element of server) + server type (Linux, Solaris, Windows). In CDM, this definition of the name would have to be exact in the context of the technical description of the IT process / server. Since information about child elements is needed here as well, the name can not be obtained by pure inheritance as in CDM. Another example is an external education rule that specifies that Apache web servers are always installed in specific file system paths, eg / var / app. The information is only part of the installation scripts of the IT process. It would also be completely modeled in fine granular CDM modeling, since the CDM method is unable to recognize this information, although it is already implicit. The CDM processes still do not distinguish between the elements of IT process engineering and the underlying platform elements, which are usually assigned to different areas of responsibility.

The care of the data is therefore correspondingly complex and error-prone in the prior art. Furthermore, the type of modeling does not rule out that logical loops between instances or classes result in endless loops that severely hinder a generic evaluability of the structure information.

The object of the present invention is to provide a method for the generic creation of a structure tree for describing the topology of an IT method with which it is possible to collect and manage all the information required for the overall handling of an IT process in a defined structure that all processes relevant to the management of an IT process can be drawn from a data source and automated. The method according to the invention has the goal of optimally supporting the collation of all technical parameters of IT processes in such a way that the basic information for the commercial processing of the ordering process, the installation of the IT process, the monitoring of the provided IT process and the scheduling new releases can be made homogeneously from a uniform data structure. According to the invention, the description of an IT process is made in a predefined order in such a way that already acquired information is retained. If technical values for describing an IT method can be determined or calculated from other descriptive values of the IT method already recorded (inside and outside the structure tree), the description of this technical value is dispensed with according to the invention. The determination of these values goes far beyond the usual inheritance of properties between parent and child elements in prior art methods. Furthermore, a device is to be provided which comprises a storage medium on which a program is stored, which can be read by a data processing system and enables the data processing system to collect all information required for the overall handling of an IT process in a defined structure and so that all automatable processes relevant to the management of an IT process are automatically performed by the data processing system.

These objects are achieved by the inventive method according to patent claim 1, a machine-readable storage medium according to claim 15 and a computer program product with program code stored on a machine-readable carrier according to claim 16.

Advantageous developments of the invention are subject matter of the dependent claims 2 to 14.

To illustrate the invention, the relationships are shown in diagrams in Figures 1 to 28. FIG. 1 shows a representation of the allowed parent-child relationships on the basis of an acyclically directed graph. The parent element Parent (1) has 2 children, namely Child 1 (2) and Child 2 (3). Child 2 (3) is also Child of Child 1 (2). It is not permissible to create the parent element Parent (1) as a child (or even child) of its child element Child 2 (3) (5), otherwise a loop would be created.

Fig. 2 shows how the names are uniquely formed in unique and non-unique elements. In this case, "label" means the proper name of the element. For non-unique elements (8, 9), the overall name is formed from the proper name and the name of the superordinate elements. FIG. 3 is shown in FIG. 2 and shows a representation of a reference (10) on an element (9).

4 shows a representation of primary and secondary relations. In secondary relations (13), which refer from a parent to a child element, the child element must already be created with a primary relation (16) to another parent element, otherwise a secondary relation is not permitted (14). In the picture, the thin line symbolizes a primary relation (16), the thick line the secondary relation (13).

5 shows an illustration of details in the structure tree of an IT method (17) using the example of the IP addresses (19, 21, 24, 28) and IP services / IP ports (20, 22, 25, 26, 29 ). Fig. 6 shows the modeling of a data connection by a secondary relation (13). The sender entity (30) sends data to the IP address 172.12.13.15 (38), port 80 (39) of the recipient entity (37). The data connection is described as a secondary relation (13) since only an existing destination port can be addressed and this port only exists if the receiver instance also exists.

FIG. 7 is derived from FIG. 6 and shows the designation of a data connection by means of a separate element (42). This is e.g. needed to describe data connections with DNS name resolution.

Fig. 8 is derived from Fig. 7 and shows a plurality of transmitters (43, 48) transmitting via a DNS connection (42) to a plurality of receivers (53, 58). For this purpose, the named data connection is assigned to a plurality of parent objects (36) which have been grouped as data transmitters within different transmitter instances (43, 48). The DNS service itself is not shown here.

Fig. 9 shows the modeling of network services affecting a data link. The data services shown here by way of example of a firewall rule (64) and a loadbalancing rule (66) are created as child elements of a named data connection (42) and linked to the elements of the associated physical components (63, 65) via secondary relations (13). Fig. 10 shows how grouping elements are inserted. The grouping elements for the two IT process groups (68, 74), the two releases (70, 71) of the IT process 1 (69) and the two installation strands A (72) and the release 1 .1 (70) belonging to B (73) are shown here hexagonal.

FIG. 11 shows the representation of an IT method (77) with two releases (78, 79), in which the middleware instances (81, 82) have been designed differently. An Apache (82) is installed on a server (80) used in Release 1 (78) and Release 2 (79). In Release 2 (79), however, the Apache 2 (81) will be installed as another Apache on this server. If the server (80), as shown in Figure 1 1, unique models, is not, or only about additional relations between the middleware instance and the release or attributes representable that Apache 2 (81) only for release 2 (79 ) belongs.

FIG. 12 shows the combination solution according to the invention of the problem set out in the description of FIG. 11. On the left side, the server is modeled non-unique in the two releases (83, 84) to illustrate the IT procedural context. It is then linked to the unique modeled physical server (89), which is unique in the enterprise, in the platform tree (88) by secondary relation (13).

FIG. 13 shows a diagram of how, when the process steps for providing an IT process are carried out, the information required for the complete installation of the IT process is provided successively. The information to be described is listed on the left, the respective information provider at the top. Hatched areas indicate missing information, in black areas the information is complete.

FIG. 14 shows how, by means of a value-source mechanism in the acquisition of new elements, the choices for names and / or attributes are restricted on the basis of the information already present in the structure tree above the element. FIG. 15 shows which differences are detected when comparing two exemplary releases (78, 79). Changes are shown in bold, such as the removal of the group INet (99) with the parent and child relations (98), the addition of the element Apache Webserver2 (87) with the relation (100) and the change of the attribute type of "Solaris9""SolarislO" in element Serverl (96, 97).

FIG. 16 shows by way of example how substructure trees are exported. The substructure tree of the illustrated sender instance (30) is detected up to its end element "Named data connection" (42) and then linked via a secondary relation to the receiver instance (I P -port, 39) Within the definition of the meta-relation For Relation (1 3) it is determined once for all these special metarelations that the export of the tree from the child element (here I P-Port, 39) contains the tree-oriented mirroring.Therefore, the tree branching up to the receiver instance ( 37) and exported to the ROOT (67), the export now contains all the information needed to model the data connection, and the information of the destination IP address (38) and the recipient instance (37) missing without this upward export is now available available in the export.

FIG. 17 shows how both the IT process installation and the monitoring of the IT process access the same data record, but represent different structure trees. Compared with the representation for the IT process installation (left), the representation of the structure tree for the monitoring (right) is inverted (note the positioning of elements 18 and 101). Both trees may contain additional grouping elements that are not relevant to the conversion, and may need to be added by other means (elements 78 and 102). FIG. 18 shows by way of example how a cluster of type a (eg Veritas) is represented. Veritas is installed here on 2 servers (107, 108) and then provides a stand-alone operating system instance (1 04) for the procedures. This operating system instance is then used quite normally by the methods, ie a procedure installation base (105) (file systems with groups and rights) is set up in which the middleware (106) and application components (not shown) are then installed. The servers can be both logi- see, as well as being virtual servers. The servers must already be up before Veritas is installed. Therefore, the connection takes place via a secondary relation (13). FIG. 19 shows the exemplary representation of a type b cluster. The data sender (sender instance 1, 43 and analog sender instance 2 48) responds to a DNS farm address (109). The DNS load balancing service (not shown here - the network equipment in which the DNS address 109 is resolved) optionally returns the IP address 172.12.13.14 (54) or 172.12.1 3.1 5 (59) as the destination. This alternately addresses the receiver instances 1 (53) and 2 (58).

FIG. 20 shows how the example clusters from FIGS. 19 and 20 are mapped onto the monitoring structure tree. In the 3 description variants for clusters (operating system clusters, global and local load balancing), the elements (104), (1 10), (1 1 1) for the monitoring are translated into the parent element "cluster" (1 14) these cluster elements (1 1 5) / (1 16) are elements (107) / (108) and (53) / (58), respectively, whereas in the operating system cluster this information can be derived immediately from the installation structure tree, In the case of the two other types of load balancing, this information must be determined indirectly by evaluating the data connections (109) or (36).

FIG. 21 shows the modeling of element-specific monitoring using the example of a web server (1 1 7).

FIG. 22 shows by way of example how the respective application parts (101) of an IT process can be assigned to the business processes (102) of a user, which can then be monitored with end-to-end monitoring tools (123).

23 shows how the IT process is planned, inter alia, with the required quantities and qualities of the servers (124, 126, 129) with the help of the substructure tree "IT process" (77) ) the assignment to the exact physical instances takes place (133, 134). Figure 24 shows a simple IT method that provides two middleware components (Apache 140 and JBOSS 141) linked (148) to one another on a virtual server (KVA1 -206v, 138). The virtual server is assigned to a physical server (RZ1 -471 1 .linux, 154) via a secondary relation (13).

FIG. 25 shows the IT method from FIG. 24, which was expanded by the database Oracle DB-KVA1 (161). Furthermore, the terminal group (159), i. the user of the IT procedure, represented as a client of the type OSS terminal group. The secondary relations (13) here show the data connections from the terminal (159) to the web server (140), from the web server (140) to the application server JBOSS (141), from the application server (141) to the database (161). Figure 26 shows how two different client groups (Internet 159, Extranet 165) access a Web server farm (140) via the DNS address www.kva1.com (233). The load balancing is controlled by the DNS service. The parameters required for this purpose (for example, load-balancing method round robin, etc.) are stored as attributes in the DNS data connection (233). The DNS name is responsible for the IT process and is unique worldwide. Therefore, the DNS name is unique and the primary child of the IT process environment (137). The data connections (147) use this name via secondary relations (13), here the relations between the elements (147) and (233).

FIG. 27 shows the use of the information of the structure tree in several target systems. Data structure for the offer definition (172), the asset definition (173), the quality assurance (174), the determination, ranking and parameterization of the installation tasks (175) are provided from the structure tree of the IT process description shown on the left (172 to 178). , object-specific monitoring (176), service-oriented monitoring (177) and IT governance (178). The data are prepared accordingly (shown here at 179, 181, 182, 184, possibly also other cases) and the appropriate data users (186, 187, 180, 188, 189, 190, 191, 183, 192, 185) posed. FIG. 28 illustrates how various tools cooperate to provide overall treatment of an IT process based on the tree of structure. On the left are the supplier systems (193) and the elements of quality assurance (1 94). The structure tree itself is held in different clients (195), which are the basis for the entry process or the installation process. The circular elements (21 9 to 223) each denote an analysis component of the structure tree. On the right are the target systems or users (196) that process the information from the structure tree.

FIG. 29 shows by way of example what a template for a technical IT process description may look like (left) and how it is used to model an IT process (right). The template for the configuration of an Apache web server on a Linux server (236, with child elements 237 to 242, 139, 147) used here comprises the basic representations of all elements required from the IT process view, starting with the Linux server ( 237), through the IT procedure installation base (139) (file systems, groups, rights) to the middleware Apache (239) and all data connectivity (238, 240, 241, 242, 147). As far as possible and reasonable, the attributes for the individual elements are pre-assigned with values, e.g. with the current version numbers of the Linux operating system and the Apache web server. In the IT process to be modeled, the template can be used for each of the two Apache web servers (246, 252).

The template is transferred in each case by means of the Smart Copy mechanism (243) in the IT process description under the IT process environment production (245).

In doing so, the given structure is duplicated and the proper names and attributes of the elements are adjusted.

In the copying process, some of the default values are manually replaced, eg, the I P address 1 72.abc (240) is read from the Apache server base (239) in the template after the smartcopy operation in the Apache (140) description. in the IT procedure replaced by 172.17.75.87 (249). Likewise, attributes can also be changed during the copying process. Figure 30 shows how a reference architecture (260, with associated child elements) uses performance elements of a service catalog (235, with associated child elements) and technical solutions (254, with associated child elements) as the description basis. The reference architecture (260, with associated child elements) is then available as an independent copy template for the modeling of an IT process description shown on the right. At the top left, the template known from FIG. 29 for the configuration of an Apache web server is shown on a Linux server. At the bottom left is a template from the field of technical solutions, in which an information server (258) is created on an OSS Windows server (256). On the information server (258), a documentation system (259) and all data-related connectivities (240, 241, 242, 147) are created as application.

The performance elements from the Apache server on Linux service catalog (236 with associated child elements) are merged together with the information server elements from the technical solutions area (255 with associated child elements) in a reference architecture (261 with associated child elements).

In the modeling of the IT process shown on the right side, both the reference architecture and other individual elements from the service catalog or from the technical solutions can be used. In general, any combination of reference architectures, service catalogs, technical solutions, and other elements (e.g., 253 and 272) would be conceivable. Thus, in the modeling of the IT process shown on the right in FIG. 30 using the smart copy method (243), both the previously described reference architecture (261, with associated child elements) and another Apache on Linux (Apache on Linux) are shown. 2, 252 with associated child elements) has been inserted; in addition, other elements became an OSS_Server virtual; z / OS Host (253) and the spec docu system (272).

The invention is based on a suitable modeling of the IT process from which all information relevant to the IT process can be displayed and processed automatically. For this it is necessary that the information self-consistent and clearly modeled. Furthermore, it must be ruled out that hidden loops can occur when the information is automatically processed. Since the modeling should already be available in the run-up to the realization of the IT process, the modeling takes place generically. This also has the advantage that even changes in the IT process topology can be handled without having to wait for concrete implementations of the elements.

The method according to the invention as claimed in claim 1 provides a method for generically creating a structure tree for describing the topology of an IT method. It models the complete environment of clients, servers, middleware components, applications, and network components that an end user needs to complete a specific IT-enabled business process. The elements of the metamodel correspond to the components of the IT process.

Each of the elements used in the structure tree is assigned a metaelement type in the meta-model. The meta-model describes which element types are allowed. The element types include all common generic IT components, such as server, middleware, storage, etc. Furthermore, it is determined which attributes are permitted and / or required for the element types and which relations with their associated attributes are allowed between the elements.

In order to ensure that no unwanted loop relationships can occur among the elements during the modeling process, only formal and loop-free topological relationships between the IT process elements are allowed by the formalism of the meta-structure. Loop freedom is achieved by using an acyclic directed graph as the meta-structure. An acyclic directed graph starts at a root element under which all elements in parent-child relationships (4) are arranged. Kindelelemente (2, 3) arrange themselves under their respective parent elements (1). The child elements may themselves be parent elements (2) of further child elements (3), but with the restriction that they may not have child elements which in turn belong to their own parent elements (5, see Figure 1). Since the formal structure of the meta-structure prevents the element elements from being assigned to a parent element even when the elements are created. can be net, which in turn are already created as their parent element, unwanted loops can not even arise.

The inventive method further ensures that a child element only ever has a relation with his / her parent element (s). You can not create a second relation between the same elements in an existing relation between parent element and child element.

For example, this restriction prevents the same server from being added to a server cluster twice.

The freedom from looping and the uniqueness of the elements create a structuring of the information contained in the IT process, which enables an automated processing of the information.

Each of the elements contained in the structure tree can be specified with attributes.

Expediently, four categories of attributes are distinguished:

1 . Attributes that are important for the context description during the installation:

For example, if you want to install an operating system instance, you must know which operating system to install in which version. When data connections are established, the IP addresses and the services addressed must be known.

2. Attributes that are important for the company organization:

It must be e.g. be known with which service level the item is operated and who in technical and technical errors for the

Support is responsible.

3. Attributes for billing the service: Services are rendered.

The purchaser and the contract conditions must be known. Some of these points are also relevant to business. Therefore, it makes sense to link this information directly with point 2.

4. Attributes for the technical finetuning of the components:

Suitable parameters for finetuning components depend on many and sometimes also on technical parameters. This detailed knowledge is irrelevant for an initial installation of an IT process. For example, a database for an IT process can be set up using simple commands such as CREATE TABLE, INSERT, .... The 500 special alparameter for configuring the database are irrelevant during the initial installation.

The information contained in a structure tree of an IT process is further processed for the overall treatment of an IT process. The recorded structure tree can be used in a variety of ways. There are always similar steps that can be summarized in special components.

There are four steps to be distinguished:

1. IT process description (visualized in tree view or graphically as a generically generated architectural image)

2. Analysis of the structure tree as a preliminary stage for data provisioning for the target systems

3. Data processing, adaptation of the data to the respective interfaces of the target systems

4. Use of the data by the target systems

An overview of the target systems is provided by FIG. 27.

Even when the information is collected, the information contained in basic structures or templates of the structure tree (170) can be further processed. The commercial target systems (186, 187) use the information by means of a converter (179) in the bidding phase. The elements modeled in a structure tree are provided with article numbers and prices. The offer management can be controlled until the conclusion of the contract.

During system planning, the information is used by Asset Management and Capacity Management (180). This supports, for example, the assignment of servers or storage in the IT process. Asset management is the asset management of an IT process. There each element is assigned its unique ID. In addition, it manages contact information for customers, contract IDs, and the like. In addition, asset management builds on capacity management, in which the total existing and the occupied or still available resources are managed in terms of volume. Asset management uses the structure turbaum (170) Information about how many resources should be allocated.

Within the framework of quality assurance, complex checking routines (181) can access the prepared data (174) in order to carry out more complex checks which go beyond the contexts previously recorded in the structure tree (170).

For the installation of the IT procedure, the information contained in the structure tree (170) is accessed in order to determine the installation tasks, to arrange them in an appropriate order (182) and to parameterize them suitably (175).

The actual installation can be monitored by a workflow component (182). The individual installation tasks are either carried out automatically by suitable scripts (189), or work tasks are set in the change management (190), which are then to be carried out manually by the responsible operations managers. The installation status is transmitted to asset management (191) and capacity management.

After the application is installed, it should also be monitored. For this purpose, on the one hand, IT-process-specific monitoring tasks recorded in the tree in the individual monitoring systems (183) can be commissioned. On the other hand, the structure tree as described in claim 12 may be machine-turned (184) and then supplied to the service-oriented monitoring system (192). Both tasks also require interpretation of the information from the specification tree (170) to set up or configure the monitoring systems. Furthermore, extracts from the information acquired in the structure tree (170) can be transferred to the enterprise architecture management (185). The information supports planning, for example, by knowing the currently used version numbers for each IT process / environment for each element, or by providing all technical data relationships between different IT processes. This supports matching against known data relationships between IT procedures.

Claim 2 describes an advantageous embodiment of claim 1. The uniqueness of the naming for the elements of the generic meta-structure is governed by unique and non-unique elements.

The decision as to whether an element is unique or non-unique is made in the metamodel. Unique elements (6, 7) are those whose proper name (generally consisting of element type and element name) occurs exactly once in the context of topology. Non-unique elements (8, 9), on the other hand, receive their unique names in the topology only because, when the element is generated, their proper name is linked to the name of the parent element to form an overall name (see FIG. 2). The proper name of non-unique items does not need to be unique.

Furthermore, only two types of relationships between parent and child elements are allowed in the metastructure. When the elements are created, a decision is made as to whether the parent-child relationship is a primary relation (16) or a secondary relation (13). Thus, if a child element (15a, 15b) is newly included in the meta-model of the IT process, it must be assigned to at least one parent element (12) via a primary relation (16). Only then can the child element (15b) also be assigned to further parent elements (11) via secondary relations (13). This means that secondary relations may only lead to elements already created in the meta-model (see Figure 4). Thus, if a child element (15a) has no primary relation, it is not possible to assign a secondary relation (14) to it.

The overall name for the non-unique elements of the platform group is formed by its proper name in association with the parent element by a primary relation defining the name. Because the overall name of the non-unique element must be unique, non-unique elements can never have more than one primary relation to a parent element. Accordingly, according to the invention, the formalism of the metastructure prevents the assignment of more than one primary relation to a non-unique child element.

When inserting a new secondary relation to an existing element, a direct reference to the existing element is created. The start and end points of all relations are defined from the names of parent and child elements of the relation.

As a further restriction in the meta-structure, only one primary relation or one secondary relation is allowed between two element types. The primary relation expresses that a child element can exist only on the basis of the parent element. On the other hand, the secondary relation expresses that the parent element uses an already existing child element. Production and use in one exclude each other. Thus, this restriction creates a linguistic and substantive specification, which will benefit the later use of the structure tree for automation purposes.

Since attributes can be assigned to every element contained in the structure tree, the properties of the elements relevant to the interaction of the elements can be recorded.

The same applies to the relations contained in the structure tree, for which the attributes of the relations which are relevant for the interaction of the elements can also be detected by means of attributes.

In claim 3 it is described how advantageous in the meta-model data connections are modeled.

Data connections describe the data exchange between sender and receiver, e.g. based on an IP connection. The sender can only send data to a receiver if the receiver exists and is ready to receive. The data connection is therefore modeled as a secondary relation (13) (see Figure 6).

In some cases, there is a need to make data connections identifiable. This is done by modeling the data connection as a separate element that has its own name (42, see Figure 7).

Especially in the case of DNS connections, a plurality of transmitters (43, 48) are combined by allowing a plurality of parent objects (36) to the named data connection (42) (see FIG. When DNS-based "load balancing", ie the load distribution to multiple target systems by means of a distribution algorithm, eg round robin, in which the target systems are assigned in turn with transactions, there are several recipients (eg 60/55 or their parents 31), the over A DNS connection can be addressed, and the data connection in the meta-model is also advantageously modeled as a separate element. On the way of the data connection, transparent services may influence the data or the data flow. For example, firewalls can prevent the accessibility of certain destinations, or load balancers can use their own algorithms to forward the data to different destinations.

Net address translation (NAT) and port translation may also be such services. The engagement in a data connection is advantageously modeled in the meta-model as a child element (64, 66) to a named data connection (42). For example, a firewall rule (64) can be attached to a named data connection as a child element. Here it must be ensured that only the firewall rule is appended as a child. The firewall itself is modeled as an IT component (63), since the technical device itself is managed via IP connections (see Figure 9). By the same methodology described herein, other synchronous and asynchronous data connections may also be described, e.g. Fiber Channel connections, file transfers and message queues.

According to claim 4, the structure trees can be structured in a clear and easy to maintain manner by applying groupings of elements (see Figure 10). For this purpose, grouping elements that also have attributes can be modeled using both unique and non-unique elements.

For each group representation, a separate branch is created in the specification tree. Such substructures can also be used to model the IT process from different points of view. Using primary and / or secondary relations, the substructures can be interconnected. Thus, for example, groupings can be modeled that associate the IT process (77) with a generic IT process group (76, eg all IT processes of a specific customer). The IT procedure (77), for its part, can be divided into individual releases (78, 79), and a platform group (88, also referred to as a platform tree), in which the physical components are shown concretely. This enables an efficient and flexible presentation of the information about the development of the IT-procedure over the different releases (see figure 1 1). In claim 5 is described how the information shown in Figure 13, required to create the structure tree information is advantageously detected and used.

The distribution, service management, release management, platform operations management, IT process management, etc. involve numerous different stations (roles, areas of responsibility) in the provision of an IT process. The modeling of the IT process of the present invention takes into account all these stations to provide a consistent and automatable basis for comprehensive management.

The basic structure of the structure tree presented in the previous claims supports the entire process.

According to claim 5, the process for acquiring the information required for a complete installation of an IT process goes through the following steps:

1 . It is advisable to work with templates (208) as a recording aid and also to facilitate linking of the technical and commercial description of an IT procedure. Particularly advantageous here is a service catalog (197) which describes the standardized power elements. The service catalog defines the performance elements, describes these performance elements in the sense of a product catalog, structurally describes these performance elements in the sense of the structure tree as a template and defines a price model for the purchase of benefits.

Another option for including templates in the creation of a structure tree is when the software is designed using a standardized software

Modeling language is created. This can be done for example in the known modeling language UML (Unified Modeling Language). The information contained in the software modeling is used to create the rough structure of the structure tree. For example, as part of the design of an application, a UML

Diagram (server components, 198). This diagram type provides information about the basic structure of an IT process. Here are the basic interconnections of the IT process included, possibly even first specifications regarding the versions to be used, such as an operating system or a web server "at least version xx" etc. This image also provides information, whether a certain software is cluster-aware or not.

It is also possible to use reference architectures and other technical solutions as copy templates for creating a structure tree of an IT process. Technical solutions are ultimately identical to service components of the service catalog, with the difference that there is no universal pricing model yet, but that the prices are agreed individually. From the perspective of the technical IT process description and its templates, there are therefore no changes. Ideally, reference architectures should be made up of service catalogs or at least technical solutions. Thus, the reference architecture is offered as a template, which normally includes several performance elements and technical solutions. In principle, however, it also offers the possibility of supplementing other elements outside the definitions of the service catalog and the technical solutions.

As part of the quotation (209, 210) to a customer, it is determined with which blocks, in which scaling a service is provided for the end customer. Here, the cost-determining factors number, performance parameters and type of the power elements to be used are determined, e.g. Number of CPUs to be used, main memory, disk space, service and performance levels. This may be, for example, how many servers of which type (124, 126, 129), middleware, database and application instances, on which environment types (125, 130 or 127, 131), operating systems, etc. to which Price and under which conditions (eg service level, operating time, ...) should provide the service.

In order to be able to fully automate a subsequent provisioning process, it is imperative that only services are provided which originate from a well-structured, database-supported service catalog (197, 208) and are thus machine-readable. It is therefore essential that a structure defined under point 1) is used when preparing the offer. Any ancillary agreement that would be stored in an arbitrary manner that does not fit the structure defined under point 1) destroyed the automation capability of the overall process.

The early, structured and complete documentation of the future environment helps to carry out the order without errors. The clear documentation ensures that no performance element to be planned is forgotten. In addition, all performance elements are described so completely that they can be installed automatically afterwards. The description in this step is still detached from the specific target environments, which are subsequently determined by the platform operations guides (88). From a business point of view, however, the description is already more concrete than the representation from any previous software development since all redundancies and quantities are already described in detail here. This is illustrated in FIG.

Based on the previously defined elements and quantities, an offer is created for the new environment to the end customer. For the individual order options, service note items are assigned that relate to the service modules in the service catalog. Possibly. After several improvements, the contract is concluded.

After the end customer has accepted the offer and has commissioned it, the IT procedure is recorded on the one hand in the commercial systems (225), and on the other hand, the entry for the automated IT process installation (214) has to be completed. Here, the detection of the IT process including specializations such as groupings, e.g. for building installation groups and creating data connections within the IT process and their IT processes. The illustrated data connections describe the "useful data traffic" of the application.Server and other IT process elements are described non-unique in this illustration, since the correct description of a single release is the focus here.

Now all those IT process elements from the process tree are assigned concrete platform instances, eg operating system instances, servers, message queue managers, etc., in the grouping of the platform tree (215 with support by 220, 226), which is assigned by Their platform nature can support several similar IT process elements. This primarily affects server / operating system instances, middleware components and network components. The creation of the platform elements is done using unique elements. The allocations are made as a secondary relation from the IT

Process element to the platform element with the proviso that an IT process element is assigned to exactly one platform element after all assignments have been completed. Some of the assignments from the IT process elements to the platform elements can be directly accessed from other data sources. For example, the assignment of a server to its network switch. In these cases, the assignment can be automated.

When defining the elements, all specific environmental conditions must be taken into account:

a. The physical sites to apply: For distributed environments, ensure that the requirements are met from a business continuity point of view. Locations are chosen in terms of data relationships within and to / outside the IT process and the availability of resources and network areas.

b. The network segments to be used and the special IT procedural IP addresses are specified. IT procedural IP addresses, e.g. Alias addresses for web servers are independent of the I P addresses of the underlying servers.

c. The host names of physical, logical, and virtual servers are set. If not already available, IP addresses for normal data traffic, backup and system management are assigned to the servers. d. The names of the middleware components and applications specified in step 2) are checked.

e. There are platform-specific additional information on the middleware and application components, such as the assignment of

IP addresses and ports if this is not already done under step 2) was. In addition, further specific details are recorded, such as the assignment of queues to the associated queue manager in MQ, f. Element-specific monitoring tasks can be defined for the individual elements, which are particularly important for monitoring the IT process. If these tasks are well structured, they can be described with a high degree of standardization so that the object-specific monitoring tools can be configured automatically. The capture process requires manual capture of information about the IT process in several places. The goal must be to be able to perform these surveys as error-free as possible and at the same time as uncomplicated and fast as possible. In the claims 6 and 7 aids are provided, which support the detection process in this sense.

The manual entry of free text sometimes leads to spelling mistakes. In order to avoid such errors, specifications for recurring expressions which limit the input possibilities of the user are defined via the meta-model according to claim 6. For example, such rule-based specifications may dictate what an IP address or web address should look like, when and how to use lowercase, etc.

A further advantageous embodiment of the invention according to claim 7 contributes to the avoidance of errors in the detection of the information for the structure tree of the IT process.

Many values can be selected from tables. Using the value source mechanism, the number of selectable values (95) from a large table can be efficiently constrained by using all information already collected in the path above to restrict the target amount (see Figure 14 (18) / (94) and (90) / (93) and (69) / (92)). Each reference to a comparison column of a selection table is formulated as one condition in the meta-model. The conditions are connected to an overall condition via an AND operation. From the table with all entries only the values would be offered (95), which fulfill the overall condition. If a formulated condition is not applicable to elements or attributes, for example the meta-element type of the condition was not used in the captured tree, this condition is skipped and not applied. In other words, the user receives a larger result set in this case.

If an attribute is entered, then the label of the corresponding element in the selection can also be taken into account.

Furthermore, it is conceivable that instead of accessing a data table with the same search terms, a corresponding access to an API or a web service takes place. API or web service returns corresponding valid values in list form. This is advantageous, for example, in the dynamic determination of valid IP addresses for an element.

Claim 8 describes how it is advantageous if already structured information about the IT method is available and should be automatically transferred to the meta-model.

Some topologies or topology components of the IT process can be directly adopted from other data sources. Thus, the assignment of network components such as switches to servers in network management systems is maintained autarkic, or the assignment of virtual systems to servers is self-sufficient under control of its own management system.

Such predetermined structures can often be exported from the management systems. After a little formatting, these structures can be imported directly into the meta model via bulk import (mass data import). The structure to be read in must refer to a unique node element below which the mass data structure is to be read.

The bulk import monitors that only allowed relationships are imported. Imported is multi-level.

First, the elements, attributes, primary and secondary relations are created or deleted. Then the relations and meta types are checked for their validity. If the check reveals that at least one primary relation or at least one metatype is not valid, the entire import process is aborted.

If the check reveals that secondary relations are no longer valid, an error list is created listing each invalid secondary relation. Invalid secondary relations must be checked manually, as these are an indication that another element is based on the further existence and validity of this relation, which is no longer valid. Such a bulk import can also be carried out online via a web service or a similar API without departing from the invention.

Claim 9 describes how already detected partial structures of the structure tree can be duplicated and inserted elsewhere in the structure tree. Frequently, multiple IT structures need to capture structures that are nearly identical. In most cases, only server names, IP addresses or one or two attributes change between these different substructures. Otherwise, these substructures are completely identical. In order to avoid having to create the acquisition from scratch again and again, a recorded structure can easily be duplicated using the Smart Copy / Smart Paste function and adapted as part of the duplication process.

When customizing, the proper names and attributes of the elements can be changed.

Elements can neither be deleted nor added. All relations are retained within the copied subtree.

Elements that are connected in the subtree only via secondary relations can not be edited, since there is only one referencing relation to these elements.

Before inserting a copied subtree, all meta-model relationships are checked for validity at the point where they are to be inserted in the meta-model. Only when it is ensured that the subtree is fully compliant with the metamodel, the copying process is physically performed.

Optionally, relations of parent elements which lie outside the cut tree can also be transferred (duplicated) to child elements of the copied subtree upon insertion onto the newly created child elements. This can affect both primary and secondary relations.

Claim 10 describes how, in the meta-model according to the invention, the conditions are advantageously created to convert the structure tree into the monitoring structure tree.

Service-oriented monitoring and service-oriented reporting focus on the end-user perspective. The end user wants to use a business process. This business process is supported by one or more IT procedures. These IT processes are based on the IT process-specific application software, which is based on middleware components and servers is provided and the various persistence layers, eg database instances uses.

The monitoring structure tree is thus mirrored below the IT process (FIGS. 17, 77) in relation to the installation structure tree.

If there were no clusters, then one would already have found a very simple mapping rule between the two trees. This simple case is shown in FIG. On the left is the structure tree of the process installation, on the right the monitoring structure tree is shown. If clusters come into play, the conversion of the structure tree into the monitoring service tree is much more difficult. In the case of clusters, three functionalities first have to be distinguished from the installation point of view: a) The application software of the clustered element shown in FIG. 18 provides internally for a data comparison between the various technical application instances, which appear to the outside as one instance. This is e.g. to a Veritas cluster too. Outwardly, the Veritas cluster places an operating system instance, e.g. Server 100c (104), ready to run internally from two physical servers, e.g. Server 100n (107), server 200-n (108). In this case, if, for example, the primary server 100n (107), after a short takeover time, the secondary server 200n (108) takes over the provisioning of the operating system instance Serve OOc (104). The servers can be both logical and virtual servers. The servers must already be up before Veritas is installed. Therefore, the connection via secondary rela- tions (13).

b) The various instances are addressed via upstream DNS-based load balancing (also referred to as global load balancing). The instances of this cluster (53, 58) are active in parallel (see FIG. 19).

c) The different instances are addressed via an upstream active load balancing (also referred to as local load balancing). The instances of this cluster are active in parallel.

Monitoring displays all these cluster types the same. From the point of view of an IT process, it does not matter how the cluster is provided technically. The only important thing is that this cluster is provided and functional. If one compares the three cluster types, one finds that all cluster variants are each initiated by a grouping element that is a child (possibly a child child) of the IT process environment (Veritas cluster (104), DNS data connection (109) for global load balancing (1 10) and local load balancing (1 1 1 with 36)). This illustration can be used to automatically generate the monitoring view as well as the graphic architectural representation of the IT process, as the figure is unique.

In order to be able to manage with a single structure tree for the IT process installation and the service monitoring, some additional information must be made in the process tree. The process tree is more detailed overall. Therefore, the monitoring tree is derived from the process tree.

For service-oriented monitoring, clusters require threshold values from which the failure of a number of these cluster elements defined by the threshold value is to be displayed in a service-oriented monitoring process and possibly evaluated as critical. The threshold values necessary for this are given as an attribute to the associated cluster group elements (Veritas cluster (104), DNS data connection (109) and local load balancing (1 1 1)), s. FIG. 20.

For the object-specific monitoring of individual elements (1 17) (eg operating system instances, middleware or database instances, every monitorable object), it is possible to define in the specification tree with which monitoring tool (1 18) these are monitored and, if necessary, with which monitoring tasks / Scripts (1 19, 120, 121). This is shown in FIG.

In some special cases, it makes sense for several different monitoring tools to monitor an item. Therefore, the monitoring tool (1 18) is modeled here as a child element of the monitored element (1 7). Service-oriented monitoring can use this information to classify the events in order to present the events in the appropriate context. The individual elements "monitoring task x" (1 19, 120, 121) each comprise a machine-readable representation of the monitoring task and the description of the associated handling instruction or the associated troubleshooting script. turbaum directly integrates a monitoring event database, which is particularly helpful for IT-process-specific monitoring.

Claim 11 describes how the generic tree trees can be adapted to also manage the enterprise-wide architecture control. As part of the company-wide architecture control, the connections of the IT processes are required from the perspective of the business processes (102). The business processes (102) are provided by one or more IT processes. For release planning, from the point of view of an entrepreneur, the existing technical dependencies between the IT procedures and within the IT procedures are therefore relevant.

The structure tree for the IT process installation can provide substantial contributions in two directions:

a. Since every synchronous and asynchronous data connection is modeled, all technically realized relationships between the IT procedures can be represented immediately. As well as all data connections to essential platform elements.

b. Elements can only be installed if exact version information is available. If you compare these version details with the release plans of the manufacturer of the elements, you will receive essential information for the company-wide architecture and license control.

In addition, the structure tree can advantageously also be supplemented for the automated IT process installation in such a way that the respective application parts within the IT processes are assigned to the business processes (102) of the customer. This, in turn, may provide a basis for establishing end-to-end active monitoring (123) or functional monitoring systems, see Figure 22. Both the end-to-end active

Monitoring tools (1 23) as well as the technical monitoring systems can be assigned monitoring tasks and instructions or solution scripts (1 19, 120, 121).

Claim 12 describes a method with which parts of a structure tree can be exported into a data format that supports the representation. archived structured data. Such a file format is formed, for example, by the Extensible Markup Language (XML).

By exporting the service rooms are u.a. an automated installation of IT processes and the automated configuration of management systems, e.g. of monitoring systems possible. These systems generally can not work directly with the internal data structures of the specification tree. For post-processing in these systems, therefore, it is possible to export according to claim 12 subtrees.

From a pre-agreed export start element of a particular type of device element (e.g., GRP environment 137), all elements created down to the endpoint element, with their associated relations, are exported in the subtree.

However, in some cases, the purely downstream export does not include all the information needed to install an IT process. This is e.g. when modeling a data connection. In the example shown in FIG. 16, the export from "sender instance" (30) contains all information up to the destination port (here "80 http", 39). In the purely downwardly directed export, however, the information is missing as to which IP address (38) and to which receiver instance (37) this port belongs.

In order to add this important information to the export, with defined relations all relations upwards are exported. From the point of view of export, the tree is thus mirrored and co-exported at these points. In principle, this additional upward export could be co-exported for each element. However, for practical reasons, especially in order not to make the export unnecessarily large, it is advisable to carry out this mirrored export only if it is definitely needed. The definition of when the export should additionally be up to the root element (67) is given as an attribute to the metarelation leading to the relevant child element. In the definition, it is additionally distinguishable whether only primary or secondary relations are to be exported upwards. Furthermore, it is possible to perform exports of structures via an API / web service in the described manner online.

Claim 13 describes a method for planning and implementing an upgrade for an IT method using structure trees applied according to the invention. When upgrading an IT process, it usually does not make sense to completely dismantle the old release and then completely rebuild the new release. For this reason, it is desirable to determine the differences between two planning statuses of releases, or the differences between two subtrees. The comparison is made according to claim 13, by first exporting the structure tree of the existing release in a file format that supports the presentation of hierarchically structured data, eg in XML. This subtree will be referred to below with subtree A. Then the structure tree of the planned release is created and also exported to a file format that supports the display of hierarchically structured data. The structure tree of the planned release will be referred to below as subtree B.

Since the data are structured in uniform formats, they can be compared automatically, ie with the aid of a data processing system. The results of the comparison are also output in a structured form, whereby one or more files are created (see Figure 15).

Thus it can be quickly seen, whether an element is changed with all its attributes during the upgrade (96, 97), which elements are deleted during the upgrade (99), which relations are deleted during the upgrade (98), which elements were added during the upgrade (87 ) and which relations were added during the update (100).

It is also conceivable that one can also determine the differences between similar trees. Trees are compared by renaming the root element of sub-tree A to the label of sub-tree B before the comparison. This leads to corresponding temporary name changes of the non-unique child elements and child children of the root element of sub-tree A. These name changes can be detected and be treated accordingly in the comparison, so that by means of the method according to the invention information can be obtained in a comparable manner about the differences between two similar trees.

Furthermore, it is possible to use an API / web service to carry out the differences between two planning statuses of releases or the differences between two subtrees in the described manner online. According to claim 14, a machine-readable storage medium, for example a CD-ROM, DVD, etc. is set up so that the data stored thereon can be read out by machine so as to interact with a programmable computer system so that the computer system at least one of the in the Claims 1 to 13 mentioned processes.

According to claim 15, a computer program product is created with program code stored on a machine-readable carrier. This computer program product can run on a computer so that at least one of the methods mentioned in claims 1 to 13 is executed on the computer.

The invention will be explained in more detail below with reference to exemplary embodiments.

A user wants to use an IT process from his PC via the Internet.

As part of the quotation to a customer is now determined with which blocks and in what scale the desired performance for the end customer is provided.

Here, the building blocks should consist of a well-structured, database-based service catalog, e.g. taken from the product catalog of the provider of IT operations for an IT procedure. The data of these templates should be machine readable.

This results in the example that the IT procedure requires a web server and an application server.

The number of CPUs to be used, main memory, disk space, service and performance levels must be specified.

If the configuration of an element can not be described uniquely by a single object, the description is supplemented by further child elements for the object. For example, an operating system instance (18) may be reachable from a plurality of I P addresses (19, 21) or may provide multiple IP services (20), (22) (see Figure 5).

For example, an Apache web server (140) should be used as the web server, and a JBOSS JEE application server (141) should be used as the application server (148) that the Apache web server can send data to the ajp port (150 above) of the JBOSS JEE application server. The software application (142) is to run on the JBOSS JEE application server (141) (see Figure 24).

As a virtual IT process server containing web and application server, the OSS server KVA1 -206v (138) is used.

The IT process should be installed automatically and integrated into the company-wide architecture control of the user. Furthermore, reporting on the availability of the IT procedure and its elements as well as service-oriented monitoring and incident management of the IT procedure should be ensured to the user without any additional effort. In addition, the provider wants to settle the services without further administrative overhead.

For this purpose, it is necessary to collect and manage the technical and commercial data of the IT process in a defined structure so that all processes relevant to the management of the IT process can be automatically drawn from a data source.

For this purpose, all components of the IT process are now modeled self-consistent, unambiguous and loop-free according to the invention.

First, all permissible element types are defined. These include all common generic IT components, such as server, middleware, storage, etc. Furthermore, it is determined which attributes are permitted and / or required for the element types and which primary and secondary relations and their associated attributes are permitted between the elements.

The virtual OSS server belongs to the element type Server, the web and application server to the element type Middleware and the software application to the element type Application. The attributes permitted or required for the respective element types are used to record and manage the information relevant to the installation and maintenance of the IT process. In addition, additional information can be created.

Based on this structured information, a structure tree is now created to describe the topology of the IT process, which is based on an acyclically directed graph as the meta-structure. The structure tree starts with a root element. All elements of the IT process are now hierarchically arranged in parent-child relationships under the root element. The formalism of the meta-structure prevents a child element from being assigned to a parent element, which elements are already created as their parent element. As a result, unwanted loops can not arise at all (see FIG. 1).

It is advisable to work with templates as a recording aid and also to facilitate linking the technical and commercial description of the IT process. The central element here is a service catalog that describes the standardized performance elements.

The service catalog defines the service elements. Thus, the Apache server in this example is a web server of certain types, based on a Linux server (OSS process server) with defined file systems. In the service catalog these performance elements are described literally in the sense of a product catalog and structurally in the sense of the structure tree as a template. In addition, the service catalog contains a price model for the purchase of benefits.

The servers are pre-modeled in the template from the service catalog based on the Linux server. The OSS virtual process server (138) is the parent of the IT policy installation base (139) through a primary relation, thus the basis for its installability. The IT procedure installation base (139) defines a file and rights structure in which the other IT process components (here the Apache web server (140) and the JBOSS JEE application server (141)) are installed.

The middleware components running on the IT procedure installation base are created via primary relations as their child elements.

For the sake of clarity, FIG. 29 only shows how a template for the Apache-on-Linux configuration is transferred to the modeling of an IT method. The template for the configuration of an Apache Web server and a JBOSS application server on a Linux server (237) used here includes all elements required from the IT process view, beginning with the Linux server (237), via the IT procedure installation base (file systems , Groups, rights) (139) to the two middlewares Apache (239) and the JBOSS (not shown in FIG. 29) and all data-related connectivities (240, 241, 242, 147, again without JBOSS components). As far as possible and reasonable, the attributes for the individual elements are pre-assigned with values, eg with the current version numbers of the Linux operating system and the middleware server. The template is then transferred to the IT process descriptions (right in Figure 29) using the smart copy mechanism (243).

In doing so, the given structure is duplicated and the proper names and attributes of the elements are adjusted. The Smart Copy process (243) can not delete or add items. All relations are retained within the copied subtree. Elements that are only connected via secondary relations in the template structure can not be edited, as there is only one referencing relation to these elements.

Before inserting the copied subtree into the structure tree of the IT process to be created, all meta-model relationships are checked for validity at the point at which they are to be inserted in the meta-model. Only when it is ensured that the subtree is fully compliant with the metamodel, the copying process is physically performed.

In the example, the template "Apache-and-JBOSS-on-a-Linux-Server" is used once as part of the IT process description, resulting in the structure tree of Figure 24. In the copying process, some of the default values are replaced manually, for example replaced the Ipid 172.xyz of the Apache server with 172.1 7.75.87 (144).

Likewise, attributes can also be changed during the copying process.

It is important that when using copy templates valid rules of the meta model are not undermined. For example, in the example shown in FIG. 29, as the meta-element type for the copy template "GRP template Linux; Apache-on-Linux "(236) The first child of this template is the meta-element type" OSS-Linux-Server-virtual "(237). Make sure that the meta-model type of the copy template (here "GRP template Linux; Apache-on-Linux" (236)) is only used in those places where the meta-element type "OSS-Linux-Server "virtual" (237) is used. Consequently, it is not possible to define a generic element type "template" that will record all element types as the first child, otherwise it would allow a middleware component (140) without a server (247) directly to an IT process environment (FIG. 245) would be attached, which would technically not be able to run because of the then missing operating system.Therefore one needs for each Kindelementtyp, which initiates a template (here eg the Linux server virtual (237)), in each case own Metaelemente (here eg "GRP template-Linux; Apache-on-Linux "(236)) for defining copy templates, but you do not need a separate meta element for each service element of the service catalog, for example, it is easily possible to build all templates based on the" GRP template Linux "meta element type. Linux-based servers, such as Apache-on-Linux (236), JBOSS-on-Linux, Apache-and-JBOSS-on-a-Linux-Server, Apache-and-Linux-on-two separate Linux servers, etc

After inserting the template Apache-and-JBOSS-on-a-Linux-Server in our example in Figure 24 the application KVA1 -JEE (142) installed on the JBOSS server will be displayed as a child element of the JBOSS server (141) created.

In this example, it would also be conceivable that the template used is a UML diagram that is developed as part of the development of a new application for the IT process.

The application to be developed is then modeled in the modeling language UML. From this, a UML diagram is created that already contains information about the basic structure of the IT process. This UML diagram (198) is converted so that it can be used as a template (208) for the IT process description according to the invention. This template contains information about which types of items are used in the IT process and how they are linked together through installation prerequisites and data connections. Thus, in this example, below the root element "root", the structure tree shown in FIG. 24 results.

On the left side, the parent GRP elements (135-137) of the IT process description are initially created. They serve to structure the IT processes of customer A. The IT process considered here is specified more precisely by the subordinate elements customer process A1 (136). Associated with this is the GRP environment production (137). This is followed by the already mentioned IT process servers.

On the right side under the superordinate element GRP Area Data Center Production (152) the IT platforms that can be used by the IT procedures are listed. These physical components are associated with the virtual components from the IT process description.

Some of the attributes and additional information about the elements will be presented below.

In order to properly install an operating system instance (i.e., a virtual server) in a data center, information on the required performance class (CPU power, main memory, ...) as well as safety information (e.g., site / fire section, ...) is needed. This information must then also be taken into account when assigning it to a physical server, as well as when assigning the I P addresses. The virtual OSS server must therefore be described by these attributes.

The IT procedure installation base (139) defines a file and rights structure in which the other IT process components (here the Apache web server (140) and the JBOSS JEE application server (141)) are installed. Typical attributes for this IT process installation base are:

• Username and UserID

• Groupname and GroupID

• path and filesize

• Backup presets

• security zone

• Installation order (zero = default, positive value = first, second, third, negative value = last, penultimate, ...) For the various middleware components, such as. the Apache Web server (140) or the JBOSS JEE application server (141), special parameters are required, such as: For example, the version number of the middleware, possibly the version number of a directly connected component such as the underlying Java virtual machine, information about the startup behavior and backup or information on the service level of the middleware component.

Many details, such as the standard file systems of these middleware components, do not need to be modeled. Everything that implicitly results should not be modeled with. In the foreground should always be that only that is modeled, which also must be able to be modified from an IT process perspective. Also for the applications (142) there are special details, such as the version of the application or path to find the application.

When requesting the IP address and also for subsequent decisions (for example with firewall rules), it must be clear in which network segment and which VPN the IP address is needed. In addition, server-side often several network cards are available. Here you may want to specify via which of these interfaces the IP address should be routed. The IP service must clearly define which IP service (name, e.g., http, https, ajp, ...) is assigned to which port or port, and whether the ports are to be created for UDP or TCP.

When the structure tree of the IT process is created, it is then passed to the commercial analysis method (Kfm, 219) according to FIG. 28, which determines the required article numbers of the service catalog (1 97) from this information (224) and then provides a first price information for created the customer. The commercial treatment could already be done, if not all technical details are known. For the commercial treatment, it is irrelevant, for example, whether the IP address 172.12.13.14 is awarded, because it may be sufficient to know that an IP address is even requested, and even this information may be obsolete commercially.

If the interest in the customer of the IT procedure has been aroused, a concrete offer (210) is again requested with the aid of the commercial analysis method (Kfm, 219) and a contract is concluded and deposited (225). Since an offer has a legal obligation, prior to the request for the offer, the IT process description will be transferred to the client "Soll kaufmännisch" (21 1), in which no changes can be made during the preparation of an offer in the client "Is commercial" (212). The offer can be requested either for the complete IT process environment, or (by comparing "target commercial" and "is commercial") only to the extent of the required changes (199).

If the offer is error free, as determined by the analytical method "QS Commercial" (200), and is the commissioning of the implementation of the sales department released, the detailed scheduling of the IT procedure in client planning (213) takes place through the release management (214) and the system planning (215). The analysis method "QS-commercial" (200) checks whether valid article numbers could be determined and whether more complex dependencies (eg if element A is ordered with a high service level, then B must also be ordered with a high service level) in the sense of warnings, if there are serious differences between the old and the future new contract, eg price increase over 10% The system planning (and possibly also the release management) are supported by the analysis method "System Planning" (220). For example, when ordering / agreeing an IP address, structural information is evaluated, such as whether the IP address belongs to a server in the production or acceptance environment, in which security area the IP address is required and which middleware on the server should be provided. The same procedure is used for the allocation of storage. In particular, Capacity Management (226) is supported with the analysis method "System Planning" (220). After the planning has been completed, the planned IT process description is initially quality-assured.

Within the framework of commercial quality assurance (200), it is first checked whether there are no deviations (199) between the planning status and the status "commercial target" or "commercial" (depending on whether the workflows in the commercial systems have already been completed If deviations occur, it must be ensured that the commercial systems are brought into line with the state of planning at short notice, but only if the planning status is passed on to all technical (commercial and technical) departments. Requirements are sufficient.

This is followed by technical quality assurance (207). From a technical point of view, various checks are carried out here, eg whether the assigned IP address meets the requirements of the server. This check is necessary because it can not be ruled out that the subsequent change of an attribute has not yet changed the decision criteria for assigning this IP address. If this is the case, then the planning must be changed accordingly before the application is to be installed. The planning is now complete. As soon as the sales department gives the start signal, the installation can begin.

Once all quality assurance measures have been successfully completed, the planning status is transferred to the client "To-be-installed" (21 7), where it can no longer be changed.The QS routines finally confirm the correctness of the planning, after which the installation begins. The analysis method "Install" (221) determines the installation tasks and allows them to be executed. The execution is either automated by means of suitable installation scripts (227) or by the creation of change requests to the change management (228). All these tasks are under the control of Install (221).

Upon completion of all installation jobs, "Install" (221) reports the conversion to the billing systems (229) so that the customer of the IT process can now be billed.

The analysis method "Mon" (222) updates the monitoring jobs for the object-specific monitoring systems (231) of the platform (Unix monitoring, web server monitoring, application monitoring, etc.) as well as for central business service monitoring (230), in which the Alarm messages from the different object-specific monitoring systems are correlated with each other.

The analysis method "Gov" (223) transfers information from the Installed client (218) to Enterprise Architecture Management (232), such as information about the components used and their versions, and information about the technical data relationships in the IT procedures.

In a second example, a given IT method is extended to include a separate database server (160) and a client (159). This is shown in FIG.

The terminals are not modeled individually. However, in order to be able to create firewall rules automatically, the groups must be displayed on terminals in the IT procedure. Here, an example of a client is shown, who accesses the IT process via the Internet. Via attributes, this client (type OSS terminal group) receives the information about which VPN it is accessing.

The database is initially modeled exactly like any other middleware component. A virtual server (160) is modeled on which an IT server Process installation base (139) for the database (161) is created (ie file systems, groups and rights). The database (161) is then created on this IT procedure installation base. The database receives some additional information about attributes that are important for the installation of the database, such as the database version, the character set, the SID, information on the sizes of the required file systems and the backup process.

Additional child elements for the database instance can be used to describe additional patches or software options to be applied. The creation of tablespaces can also be described in this way.

Database clusters such as For example, Oracle dataguard is described by inserting it as a parent element above the Oracle instances.

In the next example, a given IT procedure is supplemented by a thread which is addressed via a global load balancer. Figure 26 illustrates how two different client groups (159, 165) use the DNS service (233) to address a farm of web servers. The clients address the DNS address www.kva 1.com. The DNS service resolves this address and alternately outputs the IP addresses and ports of the two Web servers (ie 172.17.75.87 (234) or 172.17.75.88 (166) with port 80j as the destination address one or the other address will result from the selected load balancing procedure, most of which will be round-robin The load balancing procedure will be indicated as an attribute at the DNS address The DNS address {www.kva 1.com) is the responsibility of the IT process operations manager. It belongs to the respective IT process context and is unique for the respective DNS services. Therefore, this DNS address is modeled unique. She is the primary child of the IT process environment (1 37). This DNS address is used by defining it as a secondary child of one or more data connections (147) and in turn receiving the destination ports (146) as a secondary child.

Another example explains the use of unique and non-unique elements: An Apache (82) is installed on a server (80) used in Release 1 (78) and Release 2 (79). Now in release 2 (79) another Apache (Apache2, 81) will be installed on this server (80).

If the server was modeled in a unique way, it could only be expressed via the tree via additional attributes or links that the Apache2 (81) is only valid in Release 2 (79) (see Figure 1 1).

If you model the server non-unique, you can already use the structure tree to express that apache (85) is relevant in release 1 (78) and apache (86) and apache2 (87) in release 2 (79). The server (83, or 84) receives in this variant its name (not the label) with respect to the parent element release. In this representation, however, one loses the information that the servers (83 and 84) in Release 1 (78) and Release 2 (79) are identical. The label is the same, but not the name.

To be able to express directly in the structure tree that the two Apache2 and Apache2 in the two releases run on the same physical server, the server is modeled twice: In the so-called process tree (left in Figure 12, below the process group (76)) he models non-unique (83 or 84). In the platform tree (on the right in FIG. 12, below the platform group (88)) it is modeled uniquely (89). The relationship between these server descriptions is established via a secondary relation (13), s. FIG. 12. In this combination solution, the platform tree is made available directly via import mechanisms. The recording of the process tree and the link to the elements in the structure tree is done manually in the context of commissioning the acquisition of operations.

Another example describes how the information from the specification tree is used for automated IT process installation.

For automated installation, for example, all information in a suitable format, eg. B. exported in XML (or provided in an API) and passed an installation machine. The installation machine determines the complete installation parameters for each element from the tree and determines the installation order of the elements. The installation parameters for each element are found by the automaton in the attributes of the IT Procedural elements, as well as in the attributes of his parents and child elements, and possibly also in the attributes of the parent or child elements of one of his child elements. Element-specific configurations and tuning parameters are accessible via references to other data sources. Possibly. In this step, the differences between the existing and future release status of the IT process environment are also determined, so that only the changes need to be installed.

In determining the installation tasks (175), e.g. determined that a Linux server, an Apache web server, an application server and a database should be installed. The algorithm in this example determines that the database has already been properly installed in a previous release, so this installation task can be skipped. The sequence of tasks sequentializes the installation tasks and puts them in an appropriate sequence. Thus, the underlying Linux server is first installed before the Apache web server is installed. In order for the installation task to be carried out, a suitable parameter set must be transferred to the installation scripts. Also this is detected out of the tree. The actual installation is monitored by a workflow component. The individual installation tasks are either carried out by means of suitable scripts, or work tasks are set in change management, which are then to be carried out manually by the responsible operations managers. The installation status is transmitted to Asset Management and Capacity Management.

Finally, excerpts from the information collected in the structure tree can also be transferred to Enterprise Architecture Management (178). The information supports the planning, for example, by knowing the currently used version numbers for each IT process / environment for each element, or by providing all technical data relationships between different IT processes. This supports the comparison against known data relationships between the IT procedures. As part of the installation process, at the latest at the end, information will be returned to the Financial Management (229), which will report on the Provision of IT process and start of service informed. Thus, then can be started with the settlement of benefits.

Finally, the use of templates for the modeling of frequently used IT process parts will be discussed in more detail briefly with reference to FIGS. 29 and 30.

FIG. 29 shows by way of example what a template for a technical IT process description may look like (left) and how it is used to model an IT process (right). The template for the configuration of an Apache web server on a Linux server (236, with child elements 237 to 242, 139, 147) used here comprises the basic representations of all elements required from the IT process view, beginning with the Linux server (237). , on the IT procedure installation base (139) (file systems, groups, rights) to the middleware Apache (239) and all data connectivity (238, 240, 241, 242, 147). As far as possible and reasonable, the attributes for the individual elements are pre-assigned with values, e.g. with the current version numbers of the Linux operating system and the Apache web server. In the IT process to be modeled, the template can be used for each of the two Apache web servers (246, 252).

In the copying process, some of the default values are manually replaced, e.g. the IP address 172.a.b.c (240) is replaced from the basic representation of the Apache server (239) in the template after the smartcopy operation in the description of the apache (140) in the IT method by 172.17.75.87 (249). Likewise, attributes can also be changed during the copying process.

FIG. 30 shows how a reference architecture (260, with associated child elements) uses performance elements of a service catalog (235, with associated child elements) and technical solutions (254, with associated child elements) as the description basis. The reference architecture (260, with associated child elements) then stands as a separate copy template for the modeling of an IT process description shown on the right is available. At the top left, the template known from FIG. 29 for the configuration of an Apache web server is shown on a Linux server. At the bottom left is a template from the field of technical solutions, in which an information server (258) is created on an OSS Windows server (256). On the information server (258), a documentation system (259) and all data-related connectivities (240, 241, 242, 147) are created as application.

In the modeling of the IT process shown on the right side, both the reference architecture and other individual elements from the service catalog or from the technical solutions can be used. In general, any combination of reference architectures, service elements from the service catalog, technical solutions and other elements (eg 253 and 272) would be conceivable. Thus, in the modeling of the IT process shown on the right in FIG. 30 using the smart copy method (243), both the previously described reference architecture (261, with associated child elements) and another Apache on Linux (Apache on Linux) are shown. 2, 252 with associated child elements) has been inserted; in addition, other elements became an OSS_Server virtual; z / OS Host (253) and the spec docu system (272).

LIST OF REFERENCE NUMBERS

1. Parent element

2. child element 1

3. child element 2

4. Permitted parent-child relationships

5. Inadmissible parent-child relationship

6. Unique element, label = elements, name = elements

7. Unique element, Label = ElementA, Name = ElementA

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

9. Non-Unique Element, Label = ElementD,

Name = ElementB_ElementC_ElementD

10. Reference

1 1. Element type U, Label = ElementA

12. Element Type V, Label = Elements

13. permissible secondary relation

14. invalid secondary relation

15. a) Element Type W, Label = ElementE

15. b) Element Type W, Label = ElementD

16. Primary relation

17. IT procedure

18. Operating system instance (Bl)

19. IP address Bl

20. IP port Bl

21. IP address Bl backup

22. IP port Bl backup

23. Middleware Apache server (AS)

24. IP address AS

25. IP port 1 AS

26. IP port 2 AS

27. Middleware JBOSS Application Server (JBOSS)

28. IP address JBOSS

29. IP port JBOSS

30. Sender Instance

31. Grouping data receiver

32. IP Address 1 33. IP port 1

34. IP address 2

35. IP port 2

36. Grouping data transmitters

37. Receiver instance

38. IP address 3

39. IP port 3

40. IP address 4

41. IP port 4

42. Named data connection

43. Sender Instance 1

44. IP Address 1 Sender Instance 1

45. IP-Port 1_Sender-Instanz 1

46. IP Address 2 Sender Instance 1 _

47. IP Port 2 Sender Instance 1

48. Sender Instance 2

49. IP Address 1 Sender Instance 2

50. IP port 1 sender instance 2

51. IP address 2_Sender-instance 2

52. IP port 2 sender instance 2

53. Receiver Instance 1

54. IP_address_1 recipient instance 1

55. IP port 1 receiver instance_1

56. IP Address 2 Receiver Instance 1

57. IP port 2 receiver instance 1

58. Receiver Instance 2

59. IP Address 1 Receiver Instance 2

60. IP port_1 recipient instance 2

61. IP_address_2 recipient_instance 2

62. IP port 2 receiver instance 2

63. Physical Firewall

64. Data Service Firewall Rule

65. DNS-based loadbalancer

66. Data service DNS-based load balancing rule 67. Root element

68. IT Process Group 1 69. IT procedure 1

70. Release 1 .1

71. Release 1 .2

72. Installation strand A

73. Installation strand B

74. IT Process Group 2

75. IT procedure 2

76th IT process group

77. IT process, label: IT process, name: IT process

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

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

80. Operating system instance, Label: Serverl, Name: Serverl

81. Middleware instance Apache Webserver 2, label: Apache2,

Name: Server1 _Apache2

82. Middleware instance Apache Webserver 1, label: Apachel,

Name: Server1 _Apache1

83. Operating system instance, label: Serverl,

Name: IT-Procedure_Release1 _Server1

84. Operating system instance, label: Serverl,

Name: IT-Procedure_Release2_Server1

85. Middleware Instance Apache Webserver 1, Label: Apachel,

Name: IT-Procedure_Release1 _Server1 _Apache1

86. Middleware Instance Apache Webserver 1, Label: Apachel,

Name: IT-Procedure_Release2_Server1 _Apache1

87. Middleware Importance Apache Webserver 2, label: Apache2,

Name: IT-Procedure_Release2_Server1 _Apache2

88. Platform Group

89. Unique Element Physical Operating System Instance X,

Label: Prod_Server_X, Name: Prod_Server_X

90. Release 1 .1 with attribute: Environment

91. New middleware element to capture

92. Comparative Values 3 {IT Method, 1 IT Method 1, IT Method 1, IT Method 1)

93. Comparative Values 2 {Environment Prod, Environment Prod, Environment Test, Environment Prod,)

94. Comparative Values 1 {Server 1, Server 1, Server 1, Server 2,) 95. Result column {middleware MW-1, middleware MW-2, middleware MW-3, middleware MW-4)

96. Operating system instance with attribute: Type = Solaris 9

97. Operating system instance with attribute: Type = Solaris 10

98. Relation is deleted in Release 2

99. Group INet, will be deleted in Release 2

100. Relation is added in Release 2

101. Application Instance

102. Business Process

103. IT process environment

104. Veritas cluster operating system instance, Serverl 00c

105. IT Process Installation Base

106. middleware

107. Server 1 (Server 1 00n)

108. Server 2 (server 200n)

109. DNS data connection

1 10. Global Load Balancing Group

1 1 1. Local load balancer

1 12. I P-address

1 1 3. I P port

1 14. Cluster

1 15. Cluster Base 1

1 16. Cluster Base 2

1 1 7 element to be monitored, e.g. a web server instance

1 18. Monitoring tool, e.g. Nagios

1 1 9. Monitoring task l

120. Surveillance task 2

121. Monitoring task 3

122. Server

123. End-to-end monitoring tool

124. Plan Server 1 (#CPU, Memory #GB, Service Level, ...)

125. Middleware 1

126. Plan Server 2 (#CPU, Memory #GB, Service Level, ...)

127. Application A

128. Business Process G 1

129. Plan Server 3 (#CPU, Memory #GB, Service Level, ...) 130. Middleware 2

131. Application B

132. Business Process G2

133. Physical Server 1

134. Physical Server 2

135th GRP area, customer A-IT process

136. GRP-IT procedure, customer procedure-A1

137. GRP environment production

138. OSS server virtual, KVA 1 -206 v.linux.rz.db.de

139. Process Installation Base Unix, Process Environment

140. Middleware Instance Apache, Apache 1

141. Middleware instance JBOSS, JBOSS 1

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

143. NET IP address of the server, 172.17.75.86

144. NET IP address of the Apache web server, 172.17.75.87

145. IP connection from the browser of a client

146. NET service - IP port, http; offered by Apache

147. GRP-IP data connection, outgoing

148. IP Connection from Apache to Weblogic, Secondary Relation 149. GRP Default IP Address Server

150. NET services offered by the JBOSS server

151. I P connection to a database

152. GRP area DC production

153. GRP-IT platform Unix server

154. OSS server, physical, RZ1 -471 1. Iinux.rz.db.de

155. NET IP address 192.168.1 .186

156. NET service IP port ssh

157. NET IP Address 192.170.1 .186

158. NET service - IP port backup

159. OSS terminal group, Internet client

160. OSS server virtual, DB-246v.linux.rz.db.de

161. DAT Oracle; Oracle DB kVA1

162. NET IP address, 172.25.36.1 1

163. OSS server, physical, RZ1 -4712.linux.rz.db.de

164. NET service IP port sql

165. OSS terminal group, extranet client 166. OSS server virtual; KVA1207v.linux.rz.db.de

167. NET-I P-address 172.17.75.88

168. Graphic frontend

169. Topology Database

170. Structure tree representation

171. Tree analysis

172. Analysis Rules: Quotation Definition

173. Analysis Rules: Asset Definition

174. Analysis rules: quality assurance

175. Analysis Rules: Determination, Ranking and Parameterization of the Installation Tasks

176. Analysis Rules: Object-Specific Monitoring

177. Analysis Rules: Service-Oriented Monitoring

178. Analysis rules: IT governance

179. converter; Determination of article numbers

180. Asset Management, Capacity Management

181. Complex test routines

182. Workflow Schedule

183. Object-specific monitoring tools

184. converter; Tree-inverting

185. Enterprise Architecture Planning

186. Price information

187. Quotation service certificate

188. Person responsible; complex test routines

189. Installation Script Executor; for each element type

190. Change Management

191. Asset management

192. Business Service Monitoring

193. Supply systems

194. Quality Assurance

195th clients

1 96. Target systems / users

1 97. Service catalog

198. UML presentations from software development

199. Difference recognition between target purchase price and actual purchase price

200. Commercial Quality Assurance QS Kaufm 201. Yes branch

202. No branch

203. Branching query: error present?

204. Branching query: Implementation mandated?

205. Branching query: QS Kaufm successful?

206. Detection of Absolute Values and Differences between Target Technical and Actual

207. Technical quality assurance

208. Templates

209. Calculation Variants

210. Kfm. Offer

21 1. Target Kaufm.

212. Is-Kaufm

213. Planning

214. Release Management VBF

215. System Planning

216. Adjust and, if necessary, adjust planning

217. To-Be Installed; Should be technical

218. Installed; Is technical

219. Commercial Analysis Method, Kfm

220. Analysis Method System Planning, SP

221. Analysis Method Installation, Install

222. Analysis Method Monitoring, Mon

223. Analytical method IT Governance, Gov

224. Article numbers and price determination

225. Quotation management, contract conclusion

226. Asset Management, Capacity Management

227. Installation Agent

228. Change Management

229. Billing system, billing

230. Business Service Monitoring

231. Object-specific monitoring systems

232. Enterprise Architecture Management

233. NET DNS data connection WWW.KVA1 .COM

234. NET IP Address 172.17.75.87

235. GRP area templates; service catalog 236. GRP Template Linux; Apache on Linux

237. OSS Linux server virtual; Linux server

238. NET IP Address 172.x.y.z

239. middleware instance Apache; Apache

240. NET IP Address 172. a.b. c

241. NET-service IP port; http port 80

242. NET service IP port; https port 443

243. Smart Copy, with adaptation of IP addresses, server names, ports, etc.

244. IT procedures; customer process

245. Process Environment Production

246. GRP template Linux; Apache on Linux, inserted

247. OSS Linux server virtual; KV-linux1 -v.linux.rz.db.de

248. NET IP address 172.17.83.1 1

249. NET IP address 172.17.75.87

250. NET service IP port; http port 8000

251. NET-service IP port; https port 443

252. GRP Template Linux; Apache on Linux 2,

253. OSS server virtual; z / OS host

254. GRP submission templates; Technical solutions

255. GRP template Windows; Information sevrer

256. OSS Windows Server Virtual; Windows server

257. Procedural Installation Base Windows; process environment

258. middleware information server; Win Web Server

259. Application APPL documentation application; documentation system

260. GRP area templates; reference architectures

261. GRP template RefArch; Web standard

262. free

263. GRP template RefArch; Web standard; added

264. GRP Template Linux; Apache on Linux; added

265. OSS Linux server virtual; KV-Linux.Linux. rz.db.de

266. NET IP address 172.12.13.14

267. GRP Template Windows; Information Server; added

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

269. NET IP address 172.14.13.15

270. NET IP address 172.15.13.16

271. NET-service IP port; Http Port80 272. Middleware MW-others; Specific documentary system; added

Claims

claims

1 . A total IT handling method comprising a complete environment of clients, servers, middleware components, applications and network components required by an end user to perform a specific IT-based business process, the information required to describe the topology of the IT process in at least one tree structure be provided

• to determine the installation tasks and / or

· For automatic installation of IT components and / or

• to configure and / or set up monitoring systems to monitor individual IT elements and / or

• for configuring and / or setting up service-oriented monitoring systems and / or

• for system planning and / or

• for capacity management and / or

• for commercial analysis and / or

• for commercial quality assurance and / or

· For technical quality assurance and / or

• to create change requests to the change management and / or invoice creation and / or

• prepared and processed for use in enterprise architecture management, using for the structure tree a meta-structure that generically defines which types of IT process elements are allowed, which attributes are allowed and / or required for the IT process element types, what relations between the IT process element types are possible, and which attributes are permitted and / or required for the relations, whereby only formal and loop-free topological relationships between the IT process elements are allowed by the formalism of the metastructure, by using an acyclically directed graph as metastructure which starts with a root element and arranges all child elements under their respective parent elements, with the child elements again only for such elements May be parent elements that are not in turn among the parent elements of these child elements.

2. A method for overall treatment of an IT method according to claim 1, wherein

Unique elements are used in the topology of the metastructure whose names are contained in the topology of the metastructure once,

- Non-unique elements are used in the topology of the metastructure whose proper names are contained more than once in the topology of the metastructure, but whose overall names are uniquely identified by their overall name by linking the proper name to the name of its creation Parent element is formed,

Primary relations between parent and child elements are defined, with children of a primary relation existing in the topology until the last primary relation to that child is removed,

- Secondary relationships between parent and child elements are defined, where

a. Secondary relations may only lead to already created child elements,

b. Secondary relations may refer to child elements only if the child element has at least one primary relation,

- only one primary relation or one secondary relation between two element types is allowed by the metastructure,

- attributes can be assigned to every element contained in the structure tree,

- Attributes can be assigned to every relation contained in the structure tree.

3. A method for overall handling of an IT method according to claim 2, wherein data connections in the meta-structure are modeled as secondary relations by between one sender instance and at least one recipient instance or

- Between each one identifiable as a separate element "named data connection", which may be child element of multiple transmitter parent elements and at least one receiver instance

be created.

4. A method for overall treatment of an IT method according to claim 2 or 3, wherein

a. Grouping elements are modeled by unique or non-unique elements,

b. a separate branch is created in the specification tree for each group representation,

c. Elements from different group representations within the structure tree may be linked by primary and / or secondary relations.

5. A method for the overall treatment of an IT method according to at least one of the aforementioned claims, wherein

a. if software is developed as part of the design of an IT application, the software is developed using a standardized software modeling language, and the information contained in the software modeling is used as a master copy for the structure of the structure tree, and / or other reference structures formulated in a standardized modeling language and / or technical solutions are used as a master copy,

b. in the framework of the offer preparation using the structure defined under a, only services that are contained in a database-supported service catalog are offered, whereby the offer determines the cost-determining factors number, performance parameters and type of the service elements to be used. c. each assigned IT procedure is created in the meta-structure within an IT process group as a single release using non-unique elements, each usable platform instance is created in the meta-structure within at least one IT platform group, and

Subsequently, exactly one concrete platform instance from d) is assigned to all process elements from the IT process branches created in c) by means of secondary relations.

Method for overall treatment of an IT method according to claim 5, wherein for the manual acquisition of information regular expressions are defined which limit the input possibilities.

Method for overall handling of an IT method according to claim 5 or 6, wherein when manually capturing values for individual names and / or attributes of elements which can be selected from a large table, the number of selectable values is restricted by all being included in the path of the structure tree parent information, which can be used as conditions for the selection of the values, are ANDed together to form an overall condition, and only the values for acquisition that satisfy the overall condition are offered for selection.

Method for the overall handling of an IT method according to at least one of claims 5 to 7, wherein all elements, attributes, primary and secondary relations are imported for automatically acquiring information by reading suitably formatted mass data structures below a unique node element, then the relations and Meta types are checked for validity, and if they are found to be invalid, either the entire import process is aborted, or if only secondary relationships are affected, an error list is created that lists all invalid secondary relationships and then is validated by the user ,

Method for the overall treatment of an IT method according to at least one of claims 5 to 8, wherein an already detected sub-structure can be duplicated with its own copy function and inserted at another suitable location of the structure tree, and thereby all relations within the duplicated part are preserved

only the proper names and attributes of the duplicated elements can be subsequently adapted, elements that are connected in the duplicated subtree only via secondary relations, can not be edited, checked before inserting the copied subtree all meta-model relationships on their validity and the copying process physically only with complete conformity to the meta model is carried out.

10. A method for the overall treatment of an IT process according to at least one of the aforementioned claims, wherein in the process tree structure

- for named data connection elements that lead to elements of a cluster, attributes are created which name threshold values from which the failure of a threshold-defined number of these cluster elements in a service-oriented monitoring process is assessed as critical,

for individual elements which are to be monitored on their own, the monitoring tools are created as a child of the element to be monitored and each monitoring task is created as a child of the associated monitoring tool, the individual monitoring tasks each having a machine-readable representation of the monitoring task and the description of the associated monitoring task Include instruction and / or troubleshooting scripts.

1 1. Method for the overall handling of an IT method according to at least one of the aforementioned claims, wherein in the process tree the applications are assigned as child elements business processes of the user, which in turn as child elements one or more active end-to-end monitoring tools and / or technical monitoring - Systems can be assigned, with both the active end-to-end monitoring tools and the technical monitoring systems Monitoring tasks and / or instructions can be assigned.

12. A method for exporting a part of a structure tree according to at least one of the aforementioned claims to a file format that supports the display of hierarchically structured data, characterized in that for elements that have been created in the meta-structure with a corresponding attribute,

- from the export start element in the subtree all elements created down to the endpoint element with the corresponding relations are exported and additionally

- Starting from the endpoint of the subtree, you can also export all upwards with the endpoint element either with all related relations or only with the associated primary relations.

13. A method for planning and implementing an upgrade for an IT method using structure trees according to at least one of the preceding claims, characterized in that

a. the structure tree of the existing release is exported to a file format that supports the display of hierarchically structured data,

b. the structure tree of the planned release is created and also exported to a file format that supports the display of hierarchically structured data,

c. the files created in a) and b) are compared by a data processing system and the results of the comparison are output in a structured form, whereby it becomes apparent

- whether an item is changed with all its attributes during the upgrade,

- which items are deleted during the upgrade,

- which relations are deleted during the upgrade,

- which elements were added during the upgrade,

- which relations were added during the update. ^. A machine-readable storage medium having machine-readable control signals capable of interacting with a programmable computer system such that a method according to any one of claims 1 to 13 is performed.

A computer program product having program code stored on a machine readable medium for carrying out a method according to any one of claims 1 to 13 when the program product is executed on a computer.