Service map transformation using stored history information

Abstract

A first type of service map may be transformed into a second type of service map by adding transformation tags to the set of configuration items (CIs) presented by the service map. The transformation tags include data that may be used to link historical information associated with the first type of service map to the second type, such as information related to incidents, alerts, change requests, and other events. A second service map may be generated using the transformation tags and / or a tag-based elimination process such that the second service map displays different CIs compared to the first service map.

Description

[Technical field]

[0001] The present disclosure generally relates to converting service maps into different types using tags that allow users to modify and maintain the converted service maps using techniques associated with both types. [Background technology]

[0002] This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and / or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. As such, it should be understood that these statements are not admissions of prior art, and are to be read in this light.

[0003] Organizations, regardless of size, depend on information technology (IT) and access to data and services for their ongoing operations and success. An individual organization's IT infrastructure may have associated hardware resources (e.g., computing devices, load balancers, firewalls, switches, etc.) and software resources (e.g., productivity software, database applications, custom applications, etc.). Over time, more and more organizations have adopted cloud computing approaches to complement or enhance their IT infrastructure solutions.

[0004] Cloud computing relates to the sharing of computing resources, typically accessed via the Internet. In particular, cloud computing infrastructure allows users, such as individuals and / or businesses, to access a shared pool of computing resources, such as servers, storage devices, networks, applications, and / or other computing-based services. By doing so, users can access computing resources located in remote locations on-demand. These resources can be used to perform various computing functions (e.g., storing and / or processing large amounts of computing data). For users of businesses and other organizations, cloud computing provides flexible access to cloud computing resources without incurring large initial costs, such as purchasing expensive network equipment or spending a great deal of time establishing a private network infrastructure. Instead, by utilizing cloud computing resources, users can redirect their resources to focus on the core functions of their enterprises.

[0005] In modern communication networks, examples of cloud computing services that users can utilize include the so-called Infrastructure as a Service (IaaS), Software as a Service (SaaS), and Platform as a Service (PaaS) technologies. IaaS is a model in which providers abstract the complexities of hardware infrastructure and offer rapid and simplified provisioning of virtual servers and storage, giving enterprises access to computing power on demand. In such an approach, however, users may have to install and maintain platform components and applications. SaaS is a delivery model that provides software as a service rather than a final product. Instead of utilizing a local network or separate software installations, software is typically licensed on a subscription basis, hosted on a remote machine, and accessed by client customers as needed. For example, users can typically access various enterprise and / or information technology (IT) related software via a web browser. PaaS acts as an extension of SaaS beyond the provision of software services by providing customizability and extensibility features to meet the needs of users. For example, PaaS may provide a cloud-based development platform for users to develop, modify, and customize applications and / or automate enterprise operations without maintaining a network infrastructure and / or allocating computing resources typically associated with these functions.

[0006] As part of implementing these core functions, an enterprise or cloud service provider may maintain a configuration management database (CMDB) that stores information about hardware and software assets associated with the enterprise. Service maps provide useful visualizations for monitoring assets and identifying IT problems. However, if an enterprise desires to change the type of service map it uses, creating a new service map can be difficult due to the volume of hardware and software assets that an enterprise utilizes and the algorithms used to discover the assets. Summary of the Invention

[0007] A summary of some embodiments disclosed herein is set forth below. It should be understood that these aspects are presented only to provide the reader with a brief summary of some embodiments, and that these aspects are not intended to limit the scope of the disclosure. Indeed, the disclosure may encompass a variety of aspects that may not be described below.

[0008] Thus, the techniques disclosed herein may improve the efficiency of certain operations associated with monitoring and maintaining assets (e.g., configuration items (CIs) such as hardware assets, software assets, and licenses) managed by a configuration management database (CMDB). For example, a processor may receive a request to convert a service map from a first type to a second type, such as converting a manual service map to a tag-based service map. In general, a service map is a visual representation of relationships (e.g., connections and dependencies) between multiple assets. The assets displayed on the service map may be manually selected or entered (e.g., manual service maps) or built based on removal criteria (e.g., tag-based service maps). In either case, it may be advantageous to convert the manual service map to a tag-based service map while retaining certain information recorded for the manual service map (e.g., records and historical information, etc.). Thus, a subset of the assets displayed on the service map may be identified for tagging with a conversion tag that points to the pre-converted manual service map and the converted tag-based service map. After tagging a subset of the CIs or all of the CIs with the conversion tags, a service map generation technique (e.g., a tag-based technique) may be applied to generate a converted service map (e.g., a converted tag-based service map). By including the conversion tags in the CIs, tickets (e.g., incidents and change requests, etc.) and other historical information may still be linked from the previous service map to the converted tag-based service map, thereby allowing a user to convert to a different type of service, minimizing or preventing information loss that may otherwise occur. Additionally, the included conversion tags may facilitate the dissemination of updates made to the CIs. For example, a user who updates the service maps (e.g., other converted service maps, tagging-based service maps, and manual service maps) and / or the CMDB, such as by modifying information associated with the conversion tags, may trigger updates to additional service maps that include the CIs affected by the modified information.In this manner, the conversion tags added during the disclosed conversion process may facilitate converting service maps to new types without losing functionality.

[0009] Various refinements of the above-mentioned features may exist in relation to various aspects of the disclosure. Additional features may also be incorporated into these various aspects as well. These refinements and additional features may exist individually or in any combination. For example, various features discussed below in relation to one or more of the described embodiments may be incorporated alone or in any combination into any of the above-described aspects of the disclosure. The brief summary presented above is intended only to familiarize the reader with some aspects and contexts of the embodiments of the disclosure without limiting the claimed subject matter.

[0010] The various aspects of the disclosure may be better understood upon reading the following detailed description and upon reference to the drawings, in which: [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram of an embodiment of a multi-instance cloud architecture in which embodiments of the present invention may operate. [Diagram 2] FIG. 1 is a schematic diagram of an embodiment of a multi-instance cloud architecture in which embodiments of the present invention may operate. [Diagram 3] FIG. 3 is a block diagram of a computing device that may be utilized in a computing system that may be present in FIG. 1 or FIG. 2 in accordance with an aspect of the disclosure. [Figure 4] FIG. 2 is a block diagram illustrating an embodiment in which a virtual server supports and enables client instances according to aspects of the present disclosure. [Diagram 5] 1 is a block diagram of an embodiment of an electronic computing and communication system for discovering and / or managing connected configuration items (CIs) connected to a network in accordance with an aspect of the present disclosure. [Figure 6]4 is a flow diagram of an embodiment of a process for transforming a service map using transformation tags in accordance with an aspect of the present disclosure. [Figure 7] 4 is a flow diagram of an embodiment of a process for updating a service map using translation tags according to an aspect of the present disclosure. [Figure 8] 1 is a screenshot of a service map according to an aspect of the present disclosure. [Figure 9] 1 is a screenshot of a condensed map associated with a converted service map, according to an aspect of the present disclosure. [Figure 10] 1 is a screenshot of a portal displaying a record having fields that store information from conversion tags, according to an aspect of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] One or more specific embodiments will be described below. In order to provide a concise description of these embodiments, not all features of an actual implementation are described herein. It should be understood that the development of any such actual implementation, like any engineering or design project, requires numerous implementation-specific decisions to be made to achieve the developer's specific goals, which may vary from implementation to implementation, such as compliance with system-related and enterprise-related constraints. Moreover, while such a development effort may be complex and time-consuming, it should nevertheless be understood by those of ordinary skill in the art having the benefit of this disclosure that such a development effort is a routine undertaking of design, fabrication, and manufacture.

[0013] As used herein, the term "computing system" refers to an electronic computing device, such as, but not limited to, a single computer, virtual machine, virtual container, host, server, laptop, and / or mobile device, or multiple electronic computing devices working together to perform the functions described as being performed on or by the computing system. As used herein, the term "media" refers to one or more non-transitory computer-readable physical media that together store the content described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and / or random access memory (RAM). As used herein, the term "application" refers to one or more computing modules, programs, processes, workloads, threads, and / or sets of computing instructions executed by a computing system. Exemplary embodiments of an application include software modules, software objects, software instances, and / or other types of executable code. As used herein, the term "Configuration Item" or "CI" refers to a record for any component (e.g., a computer, a device, a piece of software, a database table, a script, a web page, a piece of metadata, etc.) in an enterprise network, and associated data such as manufacturer, vendor, location, or similar data for any component in the enterprise network, stored in a CMDB, etc.

[0014] An information technology (IT) network may include a number of computing devices, server systems, databases, etc. that generate, collect, store, and distribute data. A graphical user interface (GUI) may provide interactive objects that a user may view and / or manipulate to facilitate the use of this data. As GUIs become more complex, it may become more difficult to identify the characteristics of interactive objects in the GUI.

[0015] With this in mind, an IT system may include service map logic that generates an accurate, service-aware view (e.g., a "service map") of the system infrastructure that is frequently refreshed and keeps the view up to date. Service maps may be built by discovering and mapping relationships between IT infrastructure and updating the service map in real time for changes that affect services. Service maps may provide a mix of applications and IT components that support services and provide an understanding of how these applications and components are related.

[0016] A service map may be generated using a variety of techniques, such as manual techniques (e.g., techniques resulting in a "manual service map") or tag-based techniques (e.g., a "tag-based service map"). Generally, a manual service map may be generated by a query that results in CIs that match the criteria of the query and assigns and / or connects the CIs to yield a service map. More specifically, in an example where a manual service map is generated using a query, a user may submit a query that indicates one or more criteria associated with an asset, such as an asset type (e.g., a server) that runs a particular operating system. Thus, a software application used to generate the service map may discover CIs that meet the one or more criteria specified by the query. In an example where a manual service map is generated by connecting CIs, a service CI may be created (e.g., identified via discovery), and one or more CIs downstream of the service CI may be connected to the service CI. Additionally, one or more additional CIs downstream (or upstream) of the connected CI may be added to the manual service map. In this manner, the service map may indicate directional relationships (e.g., indications of resources that run on other connected resources (e.g., upstream or downstream resources)) that may improve the efficiency of monitoring of the CIs depicted in the service map.

[0017] As mentioned above, service maps may also be generated using tag-based techniques (e.g., resulting in a tag-based service map). Generally, a "tag" includes a key-value pair that points to information associated with a CI. In at least some examples, a "tag" may be associated with a CI based on user input. In some embodiments, a service map may be generated using tags such that the resulting service map provides a visualization of CIs that have a particular tag and directional relationships (e.g., CIs downstream of a CI that has a particular tag). In this manner, generating a service map using tags may enable IT personnel to generate service maps more efficiently by providing additional criteria for eliminating certain CIs.

[0018] In at least some embodiments, such as the example where a manual service map is being generated, one or more unexpected CIs may be added to the manual service map. In general, an unexpected CI may be a CI from which a user does not want to receive data or that does not want to be included in the calculations associated with the service map. For example, a service map that includes an unexpected CI may be irrelevant to the service map, but may nevertheless indicate downtime of an application included in the service map until the service map is frozen (i.e., the unexpected CI is removed and the expected CI is added). Also, unexpected CIs may include irrelevant CIs that are related to expected CIs (e.g., a switch may be associated with a particular server) and may be downstream of expected CIs, but the irrelevant CIs may include irrelevant information that affects the calculations performed on the service map. Examples of the addition of irrelevant CIs may include network cards, files, file directories, switches, templates defined for an application, and the like. In either case, calculations involving unexpected and irrelevant CIs may utilize a relatively large amount of memory and CPU time that could otherwise be utilized for other operations. Furthermore, additional unexpected CIs downstream of the unexpected CI may be added to the service map, and / or expected CIs (e.g., that a user desires to monitor) may not be added to the service map. In any of the examples described above, the resulting service map may be inaccurate, and calculations performed on the service map may point to unexpected or erroneous results.

[0019] Thus, the present disclosure is directed to a technique for converting a first type of service map (e.g., a manual service map) into a second type of service map (e.g., a tag-based service map) using conversion tags, rather than generating a new service map using tag-based services. The disclosed technique may also provide a user with a service map with selectivity associated with the tag-based service map while allowing the user to make modifications using manual techniques. Generally, the disclosed technique includes scanning or traversing CIs in a storage structure or medium associated with the manual service map, such as a CMDB, and adding conversion tags to CIs that meet certain criteria (e.g., user-entered criteria or other methods). For example, the criteria may include a core CI class list (e.g., a CI inclusion list). Thus, the processor may add conversion tags to CIs that match CIs pointed to by the core CI class list. Generally, the conversion tag may include a key that points to the converted service map and a value that points to the current (i.e., pre-conversion) manual service map. After the CIs are tagged with the conversion tags, the manual service map may be reclassified as a converted tag-based service map. For example, the class of the service map may be changed from a "manual service map" to a value indicating a "tag-based service map." The transformed tag-based service map may be repopulated and / or recalculated based on the tagged CIs and the traversal rules associated with the tag-based CIs. Because the transformed tags of the transformed tag-based service map may identify the previous manual service map, historical information associated with the previous manual service map may be maintained. That is, historical information such as tickets (e.g., incidents and change requests) associated with the previous manual service map may be maintained. By retaining the history associated with the previous manual service map, a user may continue to manage and monitor the service map without losing data. Furthermore, the disclosed tagging of transformed tags may facilitate tracking of CIs such that updates made to one or more CIs associated with a manual service may be propagated to existing service maps.

[0020] With the foregoing in mind, the following figures relate to various types of generic system architectures or configurations that may be used to provide services to organizations in a multi-instance framework and in which the present approach may be used. Accordingly, these system and platform examples may also relate to systems and platforms in which the techniques discussed herein may be implemented or otherwise utilized. Referring now to FIG. 1, a schematic diagram of an embodiment of a cloud computing system 10 in which an embodiment of the present disclosure may operate is described. The cloud computing system 10 may include a client network 12, a network 14 (e.g., the Internet), and a cloud-based platform 16. In some implementations, the cloud-based platform 16 may be a configuration management database (CMDB) platform. In one embodiment, the client network 12 may be a local private network, such as a local area network (LAN) having various network devices, including, but not limited to, switches, servers, and routers. In another embodiment, the client network 12 represents an enterprise network, which may include one or more LANs, virtual networks, data centers 18, and / or other remote networks. 1, client network 12 may connect to one or more client devices 20A, 20B, and 20C such that the client devices can communicate with each other and / or with the network hosting platform 16. Client devices 20 may be computing systems and / or other types of computing devices, commonly referred to as Internet of Things (IoT) devices, that access cloud computing services, for example, via a web browser application or through an edge device 22, which may act as a gateway between client devices 20 and platform 16.1 also illustrates that client network 12 includes management or control devices, agents, or servers, such as a management, measurement, and detection (MID) server 24, that facilitate data communication between the network hosting platform 16 and other external applications, data sources, and services and client network 12. Although not specifically illustrated in FIG 1, client network 12 may also include connecting network devices (e.g., gateways or routers, etc.) or combinations of devices that implement a customer firewall or intrusion prevention system.

[0021] In the illustrated embodiment, FIG. 1 illustrates that the client network 12 is coupled to a network 14. The network 14 may include one or more computing networks, such as other LANs, wide area networks (WANs), the Internet, and / or other remote networks for transferring data between the client devices 20 and the network hosting the platform 16. Each of the computing networks in the network 14 may include wired and / or wireless programmable devices operating in the electrical and / or optical domains. For example, the network 14 may include wireless networks, such as cellular networks (e.g., Global System for Mobile Communications (GSM)-based cellular networks), IEEE 802.11 networks, and / or other suitable wireless-based networks. The network 14 may also use any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although not explicitly shown in FIG. 1, the network 14 may include various network devices, such as servers, routers, network switches, and / or other network hardware devices configured to transfer data through the network 14.

[0022] In FIG. 1 , the network hosting the platform 16 may be a remote network (e.g., a cloud network) that may communicate with the client devices 20 via the client network 12 and the network 14. The network hosting the platform 16 provides additional computing resources to the client devices 20 and / or the client network 12. For example, by utilizing the network hosting the platform 16, users of the client devices 20 may build and run applications for various enterprise, IT, and / or other organization-related functions. In one embodiment, the network hosting the platform 16 is implemented on one or more data centers 18, each of which may correspond to a different geographic location. Each of the data centers 18 includes multiple virtual servers 26 (also referred to herein as application nodes, application servers, virtual server instances, application instances, or application server instances), each of which may be implemented on a physical computing system, such as a single electronic computing device (e.g., a single physical hardware server) or across multiple computing devices (e.g., multiple physical hardware servers). Examples of virtual servers 26 include, but are not limited to, a web server (e.g., a unitary Apache installation), an application server (e.g., a unitary JAVA Virtual Machine), and / or a database server (e.g., a unitary Relational Database Management System (RDBMS) catalog).

[0023] To utilize the computing resources in the platform 16, a network operator may choose to configure the data centers 18 using a variety of computing infrastructures. In one embodiment, one or more of the data centers 18 are configured using a multi-tenant cloud architecture such that one of the server instances 26 processes requests from and serves multiple customers. A data center 18 having a multi-tenant cloud architecture mixes and stores data from multiple customers, and multiple customer instances are assigned to one of the virtual servers 26. In a multi-tenant cloud architecture, a particular virtual server 26 distinguishes and separates the data and other information of various customers. For example, the multi-tenant cloud architecture may assign a specific identifier to each customer to identify and separate the data from each customer. In general, implementing a multi-tenant cloud architecture suffers from various drawbacks, such as a failure of a particular one of the server instances 26 causing an outage for all customers assigned to that particular server instance.

[0024] In another embodiment, one or more of the data centers 18 are configured using a multi-instance cloud architecture to provide each customer with its own one or more customer instances. For example, the multi-instance cloud architecture may provide each customer instance with its own dedicated application server and dedicated database server. In other examples, the multi-instance cloud architecture may deploy a single physical or virtual server 26 and / or other combinations of physical and / or virtual servers 26, such as one or more dedicated web servers, one or more dedicated application servers, and one or more database servers, for each customer instance. In a multi-instance cloud architecture, multiple customer instances may be installed on one or more separate hardware servers, with each customer instance being assigned a certain portion of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefits of data isolation, relatively short downtime for customers to access the platform 16, and customer-driven upgrade schedules. An example of implementing customer instances within a multi-instance cloud architecture will be discussed in more detail below with reference to FIG. 2.

[0025] FIG. 2 is a schematic diagram of an embodiment of a multi-instance cloud architecture 100 in which embodiments of the present disclosure may operate. FIG. 2 illustrates that the multi-instance cloud architecture 100 includes a client network 12 and a network 14 that connect to two (e.g., a pair) data centers 18A and 18B that may be geographically distant from each other and may provide data replication and / or failover capabilities. Using FIG. 2 as an example, a network environment and a service provider cloud infrastructure client instance 102 (also referred to herein as client instance 102) is associated with (e.g., supported and enabled by) dedicated virtual servers (e.g., virtual servers 26A, 26B, 26C, and 26D) and dedicated database servers (e.g., virtual database servers 104A and 104B). In other words, the virtual servers 26A-26D and the virtual database servers 104A and 104B are not shared with other client instances and are specific to the individual client instance 102. In the illustrated example, to increase availability of the client instance 102, the virtual servers 26A-26D and the virtual database servers 104A and 104B are assigned to two different data centers 18A and 18B, such that one of the data centers 18 serves as a backup data center. Other embodiments of the multi-instance cloud architecture 100 may include other types of dedicated virtual servers, such as web servers. For example, the client instance 102 may be associated with (e.g., supported and enabled by) the dedicated virtual servers 26A-26D, the dedicated virtual database servers 104A and 104B, and additional dedicated virtual web servers (not shown in FIG. 2 ).

[0026] Although Figures 1 and 2 illustrate specific embodiments of cloud computing system 10 and multi-instance cloud architecture 100, respectively, the disclosure is not limited to the specific embodiments illustrated in Figures 1 and 2. For example, while Figure 1 illustrates platform 16 being implemented using a data center, other embodiments of platform 16 are not limited to a data center and may utilize other types of remote network infrastructure. Additionally, other embodiments of the disclosure may combine one or more different virtual servers into a single virtual server, or conversely, may use multiple virtual servers to perform operations attributed to a single virtual server. For example, using Figure 2 as an example, virtual servers 26A, 26B, 26C, 26D and virtual database servers 104A, 104B may be combined into a single virtual server. Additionally, the approach may be implemented in other architectures or configurations, including but not limited to multi-tenant architectures, general-purpose client / server implementations, and / or even in a single physical processor-based device configured to perform some or all of the operations discussed herein. Similarly, while virtual servers or machines may be referenced for ease of discussion of the implementation, physical servers may be substituted where appropriate. The use and discussion of Figures 1 and 2 are merely examples for ease of discussion and explanation and are not intended to limit the disclosure to the specific examples illustrated in those figures.

[0027] As can be appreciated, the particular architectures and frameworks discussed with respect to Figures 1 and 2 incorporate various types of computing systems (e.g., servers, workstations, client devices, laptops, tablet computers, mobile phones, etc.). For completeness, a brief high-level overview of components typically found in such systems is provided. As can be appreciated, this overview is intended to provide only a high-level, general overview of typical components in such computing systems and should not be considered limiting with respect to the components discussed or components omitted from the discussion.

[0028] By way of background, it is understood that the present approach may be implemented using one or more processor-based systems, such as that shown in Figure 3. Similarly, applications and / or databases utilized in the present approach may be stored, used, and / or maintained on such processor-based systems. As can be appreciated, such a system, such as that shown in Figure 3, may exist in a distributed computing environment, a networked environment, or other multi-computer platform or architecture. Similarly, a system such as that shown in Figure 3 may be used to support or communicate with one or more virtual environments or computing instances in which the present approach may be implemented.

[0029] With this in mind, an exemplary computer system may include some or all of the computer components illustrated in Figure 3, which generally illustrates a block diagram of exemplary components of a computing system 200 and their potential interconnections or communication paths, such as along one or more buses. As shown, computing system 200 may include various hardware components, such as, but not limited to, one or more processors 202, one or more buses 204, memory 206, input devices 208, a power supply 210, a network interface 212, a user interface 214, and / or other computer components useful for performing the functions described herein.

[0030] The one or more processors 202 may include one or more microprocessors capable of executing instructions stored in memory 206. Additionally or alternatively, the one or more processors 202 may include an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or other device designed to perform some or all of the functions discussed herein without recalling instructions from memory 206.

[0031] With respect to the other components, the one or more buses 204 include suitable electrical channels for providing data and / or power between the various components of the computing system 200. The memory 206 may include any tangible, non-transitory, and computer-readable storage medium. Although shown as a single block in FIG. 1, the memory 206 may be implemented using multiple physical units of the same or different types in one or more physical locations. The input devices 208 correspond to structures for inputting data and / or commands to the one or more processors 202. For example, the input devices 208 may include a mouse, a touchpad, a touchscreen, a keyboard, and the like. The power source 210 may be any suitable power source for the various components of the computing device 20, such as line power and / or battery power. The network interface 212 includes one or more transceivers capable of communicating with other devices over one or more networks (e.g., communication channels). The network interface 212 may provide a wired network interface or a wireless network interface. The user interface 214 includes a display configured to display text or images transferred from the one or more processors 202. In addition to or instead of a display, the user interface 214 may include other devices for interfacing with a user, such as lights (eg, LEDs) and speakers.

[0032] With the above in mind, FIG. 4 is a block diagram illustrating an embodiment in which a virtual server 250 supports and enables a client instance 102, in accordance with one or more embodiments disclosed. More specifically, FIG. 4 illustrates an example of a portion of a service provider cloud infrastructure including the cloud-based platform 16 discussed above. The cloud-based platform 16 is connected to the client device 20 over the network 14 to provide a user interface to network applications executing within the client instance 102 (e.g., via a web browser on the client device 20). The client instance 102 is supported by a virtual server similar to that described with respect to FIG. 2 and is described here to illustrate support of the disclosed functionality described herein within the client instance 102. The cloud provider infrastructure is typically configured to simultaneously support multiple end user devices, such as the client device 20, each of which communicates with a single client instance 102. The cloud provider infrastructure may also be configured to simultaneously support any number of client instances, such as the client instance 102, each of which communicates with one or more end user devices. As discussed above, end users may also interface with the client instance 102 using applications executing within a web browser.

[0033] 5 is a block diagram of an embodiment of an electronic computing and communication system 300 for discovering and / or managing connected configuration items. The electronic computing and communication system 300 includes one or more environments, such as environments 302 and 304, each including resources 306 and 308, respectively. Each environment 302, 304 may include one or more networks that couple the resources together in location-based, function-based, and / or common credential-based groupings.

[0034] For example, the environments 302, 304 may include customer service environments used to represent a customer service infrastructure in technical support, sales, billing, and / or other groupings. Similarly, the environments 302, 304 may include a data center and all devices coupled to one or more networks located in the data center. Additionally or alternatively, the environments 302, 304 may be distributed across multiple geographic locations. Thus, the environments 302, 304 may include any devices accessible with a user account, including resources that may be spatially distant from one another. In some embodiments, the resources 306, 308 of the environments 302, 304 may communicate with each other across the environments. However, in some embodiments, aspects of the various environments may be provided by different vendors without communication between them. In such embodiments, the resources of the heterogeneous environments may communicate using a platform (e.g., a configuration management service 310 that is part of a cloud services platform that includes a CMDB 312 or equivalent configuration management data structure). The resources 306 and 308 may include any suitable configuration items.

[0035] The configuration management service 310 may include one or more servers that provide access to and management of the CMDB 312. The configuration management service 310 may allocate or provision resources, such as application instances in resources 306 or 308 from individual environments 302 or 304. Additionally, the configuration management service 310 may create, modify, or delete information in the CMDB 312 related to resources 306 or 308. Thus, the configuration management service 310 may manage a catalog of resources in multiple environments (even though the environments may not directly communicate with each other). In the illustrated embodiment, the configuration management service 310 may include a service map transformation 311 system that generally manages or modifies properties of a service map generated based on the CIs or equivalent data structures of the CMDB 312. Using this catalog, the configuration management service 310 may discover new resources, provision resources, allocate resources, modify and / or delete resources from the catalog, in a single environment or across multiple environments. In some embodiments, these actions may be initiated as part of operations executed on the client instance 102, may be scheduled for periodic occasions (e.g., periodic discovery), or a combination thereof. For example, the client instance 102 may receive a request via its input structure to query for an identity of an application program interface (API) used by a resource to access a particular vendor / provider for the first environment 302, which is passed to the configuration management service 310 to query the CMDB 312. As another example, the client instance 102 may receive a request via its input structure to query for an identity of a user authorized to access a particular resource, which is passed to the configuration management service 310.

[0036] As previously discussed, the CMDB 312 (or equivalent data or storage structure) may be populated utilizing a discovery process that may be used to discover resources 306 or 308. Additionally, as previously discussed, the discovery process may include determining properties or attributes of resources 306 or 308 in individual environments 302 or 304 using individual management or administrative devices, agents, or servers, such as management, instrumentation, and discovery (MID) 24A or 24B. In the described embodiment, each environment 302 and 304 has its own MID server 24A, 24B. In some embodiments, a single MID server may be used where the MID server can reach multiple environments. For example, a single MID server may be used to manage both environments 302 and 304 where the MID server runs on the platform 16 shown in FIG. 1 (e.g., on the configuration management service 310). Additionally or alternatively, when the MID server 24A of the first environment 302 is accessing the second environment 304, the MID server 24B of the second environment 304 may be omitted.

[0037] As discussed herein, it may be advantageous to convert a first type (e.g., first class) of service map to a second type (e.g., second class) of service map while preserving information associated with the first type of service map and / or instead of having to reconstruct the entire service map. To illustrate the conversion of a service map, FIG. 6 is a flow diagram of an embodiment of a process 400 for generating a converted tag-based service map 402 based on a received conversion request 404. In general, the steps of process 400 may be implemented by client device 20 or a device or server in communication with such device 20. In some embodiments, process 400 may be implemented using a processor in data center 18 via client device 20.

[0038] To begin process 400, processor 202 may receive a conversion request 404 indicating that one or more service maps are to be converted from a first type (e.g., a manual service map) to a second type (e.g., a tag-based service map). For example, processor 202 may receive a conversion request via user input indicating that service map 406 is to be converted.

[0039] After receiving the translation request 404, in block 408, the processor 202 may tag one or more CIs 410 of the service map specified or pointed to by the translation request 404 with the translation tag 414 to generate a tagged service map 409. In general, to tag one or more CIs, the processor 202 may identify one or more of the CIs 410 for tagging based on user input (e.g., selection of a CI 410) or using a CI inclusion list 412. In general, the CI inclusion list 412 may include criteria (e.g., user-specified criteria) indicating certain CIs to be tagged, whether based on the type of CI, departments that use the CI, or other information that may be used to remove or not remove certain CIs. For example, the criteria of the CI inclusion list 412 may specify that an application should be tagged when a user wants to monitor the application. Additionally or alternatively, the criteria of the CI inclusion list 412 may indicate that switches or other CIs should not be tagged when the user does not want to monitor such CIs (e.g., CIs that may contain redundant information). In either case, the processor 202 may tag the CI set of CIs 410 according to the user-specified criteria and / or the CI inclusion list 412. Tagging a CI 410 associates new data with the CI, such as by adding new data to a field of a record in the CMDB 312 that contains information associated with the particular CI 410. In the described embodiment, the tagged service map 409 includes CIs 410a, 410b, 410c, and 410d tagged with translation tags 414a, 414b, 414c, and 414d, respectively. Additionally, CIs 410e and 410f are untagged. Thus, information associated with CIs 410a, 410b, 410c, and 410d, such as historical information, will be linked to the subsequent transformed tag-based service map 402. Thus, historical information obtained using the manual service map 406 may be retained for tagged CIs 410 after transformation to generate the transformed tag-based service map 402.

[0040] As shown in the illustrated embodiment, the transformed tag 414 may include a value 416 that identifies the current type of the service map (e.g., “Manual ID”). The transformed tag 414 may also include a key 418 that identifies the transformed type of the service map (e.g., “Tag-Based ID”). In general, the value 416 and / or the key 418 may include one or more strings that identify their respective information. In this manner, the service map information 418 (e.g., history information, incidents, change requests) associated with one or more CIs (i.e., those indicated by the dashed lines) may be retained even after the service map 406 is transformed. The history information 412 may include information such as incidents associated with CIs of the service map 406, such as change requests, alerts, and incidents.

[0041] After tagging the service map 406 with the transformation tags 414 to generate the tagged service map 409, the processor 202 may generate the transformed tag-based service map 402 in block 420. In general, to generate the transformed tag-based service map 402, the processor 202 may repopulate or recalculate the service map based on the CIs 410a, 410b, 410c, and 410d of the tagged service map 409 and / or using traversal rules for CI detection. For example, the processor 202 may use tag-based rules, as would be understood by one skilled in the art, to determine CIs for inclusion in the transformed service map 402, such as by comparing metadata of the CIs 410 to reference metadata (e.g., stored in the database 312) and adding a set of CIs 410 having metadata that match the reference metadata. In some embodiments, the processor 202 may cause a GUI to display the transformed tag-based service map 402 on a computing device (e.g., the computing device 20 as described with respect to FIG. 4).

[0042] In this manner, process 400 allows a user to convert an existing service map to a desired type, such as converting a manual service map to a converted tag-based service map 402. The conversion tags may not only help remove CIs that a user may not want included in a service map (e.g., converted tag-based service map 402), but may also enable users who wish to maintain service maps using manual techniques to do so by linking the conversion tags to the manual service map.

[0043] As generally described above, it may be desirable to add or remove certain CIs from an existing service map. In at least some instances, information related to certain CIs may be updated, whether due to user input, scripts, or other causes. Thus, it may be desirable to update existing service maps, whether manual service maps, tag-based service maps, and / or transformed service maps 402, based on updates made to other service maps to CIs, transformed tags, and / or tags of CIs, thereby improving the efficiency of maintaining a CMDB.

[0044] 7 is a flow diagram of an embodiment of a process 500 for updating the translated tag-based service map 402 based on changes made to the CMDB. In general, the steps of process 400 may be implemented by the client device 20 or a device or server in communication with such device 20. In some embodiments, process 400 is implemented using a processor in the data center 18 via the client device 20.

[0045] To begin the process, in block 502, the processor 202 may identify updates made to one or more CIs 410 based on a received indication. For example, the processor 202 may receive the indication in response to a user input that causes a change in information associated with the CI. For example, the change to the information associated with the CI may indicate that an application is running on a new server instead of a previous server. Thus, the indication may specify a new relationship or dependency between a first CI (e.g., an application), a second CI (e.g., a previous server), and a third CI (e.g., a new server), such as the first CI depending on the third CI instead of the second CI. In some embodiments, the processor 202 may periodically (e.g., hourly, daily, weekly, etc.) scan the CMDB 312 to determine whether any updates have been made to one or more CIs. In some embodiments, the update indication 504 may specify an update to a CI 410, such as indicating that the CI has been tagged with a conversion tag 414 or that the conversion tag 414 has been changed. Thus, based on the update, one or more CIs of CIs 410 of transformed service map 402 may be deleted (e.g., may not be present in transformed tag-based service map 402 as compared to service map 406). It should also be noted that in some instances, changes to transformed tags 414 may result in one or more CIs being added to service map 410.

[0046] After identifying one or more updated CIs, the processor 202 may update the transformed tag-based service map 402 at block 505 to generate an updated service map 506. Generally, the processor 202 may repopulate or modify one or more transformed tag-based service maps 402 with CIs 410 tagged with updated transformed tags 414. That is, manual changes made to CIs 410 with transformed tags 414 may cause the processor 202 to determine the transformed tag-based service map 402 to include the changed CIs 410 and update the transformed tag-based service map 402 accordingly. Generally, the service map 402 may be updated by repopulating the transformed tag-based service map 402 in a manner generally similar to that described for block 420 of process 400 with respect to generating a service map. As shown in the illustrated embodiment, the transformed tag-based service map 402 includes CIs 410a, 410b, 410c, and 410d that are tagged with transformed tags 414a, 414b, 414c, and 414d, respectively. The updated service map 506, as compared to the transformed tag-based service map 402, still includes CIs 410a, 410b, and 410d and their respective transformed tags 414a, 414b, and 414d, but CI 410c is not present in the updated service map 506.

[0047] In one non-limiting example of an implementation of process 500, processor 202 may receive an indication in response to a modification to a relationship or a newly added relationship, such as a result of a new application being installed on a server. Thus, processor 202 may identify the new relationship (i.e., the execution of the new application on the server, and "Runs on::Runs" indicating that the server is running the new application). Thus, processor 202 may tag the new application (e.g., based on the CI containment list) and proceed to block 505 to update service map 402 to include CIs 410 associated with the new or modified relationship. For example, processor 202 may update service map 402 to include the server running the new application.

[0048] In another non-limiting example of an implementation of process 500, the processor may receive an indication in response to a CI upgrade (i.e., a new version of an application has been released, more RAM has been added to a server, and other changes that affect the attributes of the CI). Thus, the processor 202 may tag the upgraded CI (e.g., based on the CI inclusion list) and proceed to block 505 to update other service maps 402 to include the upgraded CI 410.

[0049] In another non-limiting example of an implementation of process 500, processor 202 may receive an indication in response to a change in a CI tag key or value. For example, a tag-based service map may be configured to show CIs having a first tag value (e.g., “env=PROD”). Thus, if the tag value of a first CI displayed on the tag-based service map is changed from the first tag value to a second tag value (e.g., “env=QA”), updating the service map will result in removing the first CI from the service map. Other service maps configured to show CIs having the first tag value but not the second tag value will be updated similarly.

[0050] It should be noted that the disclosed techniques may allow a user to continue to modify the CIs and manual service maps using manual techniques, and modifications (e.g., updates) may be propagated to the tag-based service map. To further illustrate processes 400 and 500, FIG. 8 is a GUI screenshot 550 displaying a service map 552. In general, service map 552 may correspond to unconverted service map 406. As shown, service map 552 includes multiple CIs, some of which depend on other CIs, as indicated by the lines connecting the various CIs. For example, CI 554 depends on CIs 556 and 558. Similarly, CI 560 depends on CIs 562 and 564. However, it should be understood that service map 552 shown in FIG. 8 is merely an example, and other service maps are contemplated. For example, in some embodiments, a service map may include multiple levels of dependencies.

[0051] Because the service map 552 for a given network may contain many CIs, and each CI may be related to many different services, the service map 552 may contain a relatively large number of CIs, and it may be difficult for a user to discern relationships between the CIs as well as identify errors in CIs that may affect the operation of other CIs.

[0052] FIG. 9 illustrates an example of a transformed service map 600. In the illustrated embodiment, the transformed service map 600 includes fewer CIs as compared to the service map 552 of FIG. 8. In the described embodiment, the transformed service map 600 includes icons 602, 604, 606, 608, 610, 612, and 614, each associated with a respective CI. More specifically, the described embodiment illustrates an application service associated with icon 602, which depends on the CIs associated with icons 604, 606, 608, 610, which in turn depend on the CI associated with icon 612. The CI associated with icon 612 depends on the CI associated with icon 614. Generally, each icon includes a respective drop-down arrow that, upon selection of the respective drop-down arrow, may display information associated with the respective CI, such as incident information and alert information.

[0053] As described herein, the converted tags may be added, attached, or included to one or more CIs associated with a service map. To illustrate this, FIG. 10 shows a screenshot 650 of an embodiment of a table 652 having records 654 with associated fields that store information for different CIs or assets. For example, field 656 stores information identifying when the CI was created, field 658 stores information identifying the CI, field 660 stores information identifying a key (e.g., as described above with respect to key 418 of FIG. 6), and field 662 stores information identifying a value (e.g., as described above with respect to value 416 of FIG. 6). Thus, field 660 may identify a converted service map (e.g., as described above with respect to converted tag-based service map 402 of FIG. 6) associated with each CI. Similarly, field 662 may identify a manual service map (e.g., as described above with respect to converted service map 410 of FIG. 6) associated with the CI.

[0054] It should be understood that the specific embodiments described above are shown by way of example, and that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure.

[0055] The techniques presented and claimed herein are applied to material objects and concrete examples of a practical nature that clearly improve the art, and are therefore not abstract, intangible, or purely theoretical. Moreover, if any claim appended at the end of this specification contains one or more elements designated as "means for performing [function]" or "steps for performing [function]," it is intended that such elements be construed under 35 U.S.C. 112(f). However, for any claim that contains elements designated in any other manner, it is intended that such elements not be construed under 35 U.S.C. 112(f).

Claims

1. When executed, the processor receiving a transformation request for a first service map of a first class, the service map including a first plurality of configuration items (CIs); subsequent to receiving the request, tagging one or more CIs of the first plurality of CIs with one or more respective translation tags; determining a second plurality of CIs based on the first plurality of CIs and the one or more tagged CIs; generating a second service map based on the second plurality of CIs, the second service map being of a second class different from the first class; A non-transitory computer-readable medium comprising computer-executable instructions configured to cause

2. The machine-readable medium of claim 1 , wherein each transformation tag indicates the first class.

3. The machine-readable medium of claim 2 , wherein each transformation tag indicates the second class.

4. 2 . The machine-readable medium of claim 1 , wherein each translation tag links a change request, an incident, an alert, or a combination thereof associated with the first service map to the second service map.

5. The machine-readable medium of claim 1 , wherein the second plurality of CIs comprises the one or more tagged CIs.

6. The machine-readable medium of claim 1 , wherein the second plurality of CIs comprises a subset of the first plurality of CIs.

7. The computer-executable instructions, when executed, are configured to cause the processor to tag the one or more CIs: retrieving a CI inclusion list indicating one or more CIs for inclusion in the second service map of the second class; retrieving metadata for each of the one or more CIs that indicates a type of the CI; determining that metadata associated with the one or more CIs matches reference metadata; in response to determining that the metadata associated with the one or more CIs matches the reference metadata, tagging the one or more CIs; The machine-readable medium of claim 1 comprising instructions for:

8. 2. The machine-readable medium of claim 1, wherein the computer-executable instructions that, when executed, are configured to cause the processor to generate the second service map include instructions for reclassifying metadata to indicate the second class.

9. The machine-readable medium of claim 1 , wherein the computer-executable instructions, when executed, are further configured to cause the processor to generate a graphical user interface (GUI) that includes the second plurality of CIs.

10. receiving a transformation request for a first service map of a first class, the first service map including a first plurality of configuration items (CIs); subsequent to receiving the request, tagging one or more CIs of the first plurality of CIs with one or more respective translation tags; determining a second plurality of CIs based on the first plurality of CIs and the one or more tagged CIs; generating a second service map based on the second plurality of CIs, the second service map being of a second class different from the first class; A method comprising:

11. The method of claim 10 , wherein the request indicates that the one or more CIs are to be added to the first plurality of CIs.

12. 11. The method of claim 10, wherein the request indicates that a subset of the first plurality of CIs should be removed from the first service map, the subset being different from the one or more tagged CIs.

13. The method of claim 10 , further comprising generating a graphical user interface (GUI) that includes the second plurality of CIs.

14. The method of claim 10 , wherein each translation tag links historical information associated with the first service map to the second service map.

15. 11. The method of claim 10, wherein tagging the one or more CIs of the first plurality of CIs comprises applying a CI inclusion list to remove a subset of CIs from the first plurality of CIs.

16. The method of claim 10 , wherein generating the second service map includes converting the CI present in a manual service map into a tagging-based service map.

17. When executed, the processor Receiving a request indicating a change to a first set of configuration items (CI); identifying a service map including the first set of configuration items, the service map including a plurality of CIs including the first set of CIs; subsequent to receiving the request, tagging a second set of CIs of the first plurality of CIs with one or more respective translation tags; generating a second service map based on the second plurality of CIs; A non-transitory computer-readable medium comprising computer-executable instructions configured to cause

18. 20. The non-transitory computer-readable medium of claim 17, wherein each translation tag includes first data that points to a manual-based service map and second data that points to a tag-based service map.

19. 20. The non-transitory computer-readable medium of claim 17, wherein each translation tag links a change request, an incident, an alert, or a combination thereof associated with the first service map to the second service map.

20. 20. The non-transitory computer-readable medium of claim 17, wherein the request indicates that a subset of the first plurality of CIs is to be deleted from the first plurality of CIs.

Images