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. Accordingly, 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 continued 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 enables 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. Doing so allows users to 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 corporate and other organizational users, cloud computing provides flexible access to cloud computing resources without incurring large initial costs, such as purchasing expensive network equipment or spending significant time establishing a private network infrastructure. Instead, by utilizing cloud computing resources, users can redirect their resources to focus on their enterprise's core functions.

[0005] In modern communication networks, examples of cloud computing services available to users include 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 complexity of hardware infrastructure and offer rapid and simplified provisioning of virtual servers and storage, giving businesses access to computing power on demand. However, with this approach, users may be required 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 using a local network or individual 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 through a web browser. PaaS acts as an extension of SaaS beyond the provision of software services by offering customization and extensibility capabilities to meet user needs. 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 network infrastructure and / or allocating computing resources typically associated with these functions.

[0006] As part of performing 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 the enterprise utilizes and the algorithms used to discover 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 merely 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 related to 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. Generally, a service map is a visual representation of relationships (e.g., connections and dependencies) between multiple assets. Assets displayed on a service map may be manually selected or entered (e.g., manual service maps) or constructed 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 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 CIs or all of the CIs with the conversion tags, a service map generation technique (e.g., a tag-based technique) can be applied to generate a transformed service map (e.g., a transformed tag-based service map). By including the conversion tags in the CIs, tickets (e.g., incidents and change requests) and other historical information can still be linked from the previous service map to the transformed tag-based service map, thereby enabling users to convert to a different type of service, minimizing or preventing information loss that might otherwise occur. Furthermore, the included conversion tags can facilitate the dissemination of updates made to CIs. For example, a user who updates a service map (e.g., another transformed service map, tagging-based service map, and manual service map) and / or the CMDB, such as by modifying information associated with the conversion tags, can trigger updates to additional service maps that include 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-described features may exist in connection with various aspects of the present 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 connection with 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 provided above is intended only to familiarize the reader with some aspects and context of embodiments of the present disclosure without limitation to the claimed subject matter.

[0010] The various aspects of the present disclosure may be better understood upon reading the following detailed description and upon reference to the drawings, in which: [Brief explanation 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. [Figure 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. [Figure 3] FIG. 3 is a block diagram of a computing device utilized in a computing system that may be present in FIG. 1 or FIG. 2 according to 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. [Figure 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]1 is a flow diagram of an embodiment of a process for transforming a service map using transformation tags according to aspects of the present disclosure. [Figure 7] 10 is a flow diagram of an embodiment of a process for updating a service map using translation tags according to aspects of the present disclosure. [Figure 8] 1 is a screenshot of a service map according to an aspect of the present disclosure. [Figure 9] 10 is a screenshot of a condensed map associated with a transformed 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 INVENTION

[0012] One or more specific embodiments will be described below. In an effort 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, as with any engineering or design project, will require numerous implementation-specific decisions to be made to achieve the developer's specific goals, which may vary from implementation to implementation, including 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 an effort would be 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 that cooperate to perform 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 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.) within an enterprise network, and associated data such as manufacturer, vendor, location, or similar data for any component within the enterprise network, stored within a CMDB or the like.

[0014] An information technology (IT) network may include several 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 the 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. The service map may be built by discovering and mapping relationships between IT infrastructure and updating the service map in real time for changes that affect the service. The service map may provide a mix of applications and IT components that support the service and an understanding of how these applications and components are related.

[0016] Service maps may be generated using various 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 produce 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) running 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. Furthermore, 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., a representation of resources that run on other connected resources (e.g., upstream or downstream resources)) that may improve the efficiency of monitoring of CIs depicted in the service map.

[0017] As mentioned above, service maps can 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" can be associated with a CI based on user input. In some embodiments, a service map can be generated using tags such that the resulting service map provides a visualization of CIs with particular tags and directional relationships (e.g., CIs downstream of a CI with a particular tag). In this manner, generating a service map using tags can 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 in an example where a manual service map is being generated, one or more unexpected CIs may be added to the manual service map. Generally, unexpected CIs may be CIs from which a user does not want to receive data or that do not want to be included in calculations associated with the service map. For example, a service map that includes unexpected CIs may be irrelevant to the service map but may nonetheless indicate downtime for applications included in the service map until the service map is frozen (i.e., the unexpected CIs are removed and expected CIs are added). Unexpected CIs may also 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 may contain irrelevant information that affects calculations performed on the service map. Additional examples of irrelevant CIs may include network cards, files, file directories, switches, templates defined for applications, and the like. In either case, calculations involving unexpected and irrelevant CIs may utilize relatively large amounts of memory and CPU time that could otherwise be used 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 indicate 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 tags 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 have been tagged with conversion tags, the manual service map may be reclassified as a converted tag-based service map. For example, the class of a service map may be changed from a "manual service map" to a value indicating a "tag-based service map." The converted 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 converted tags of the converted 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 converted tags may facilitate tracking of CIs such that updates made to one or more CIs associated with a manual service map may be propagated to existing service maps.

[0020] With the foregoing in mind, the following diagrams 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 embodiments of the present disclosure may operate is illustrated. 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 that may act as a gateway between client devices 20 and platform 16.1 also illustrates that client network 12 includes management or administrative 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 customer firewalls or intrusion prevention systems.

[0021] In the illustrated embodiment, FIG. 1 illustrates that client network 12 is coupled to network 14. 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 client devices 20 and the network hosting platform 16. Each of the computing networks in network 14 may include wired and / or wireless programmable devices operating in the electrical and / or optical domains. For example, network 14 may include a wireless network, such as a cellular network (e.g., a Global System for Mobile Communications (GSM)-based cellular network), an IEEE 802.11 network, and / or other suitable radio-based network. 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, network 14 may include various network devices, such as servers, routers, network switches, and / or other network hardware devices configured to transfer data through network 14.

[0022] 1 , the network hosting platform 16 may be a remote network (e.g., a cloud network) capable of communicating with client devices 20 via client network 12 and network 14. The network hosting platform 16 provides additional computing resources to client devices 20 and / or client network 12. For example, by utilizing the network hosting platform 16, users of client devices 20 may build and run applications for various business, IT, and / or other organizational functions. In one embodiment, the network hosting 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), and each virtual server 26 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 computing resources within platform 16, network operators may choose to configure data centers 18 using a variety of computing infrastructures. In one embodiment, one or more of data centers 18 are configured using a multi-tenant cloud architecture, such that one of server instances 26 processes requests from and provides services to multiple customers. A data center 18 with a multi-tenant cloud architecture mixes and stores data from multiple customers, and multiple customer instances are assigned to one of 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, a multi-tenant cloud architecture may assign a specific identifier to each customer to identify and separate data from each customer. Implementing a multi-tenant cloud architecture typically suffers from various drawbacks, such as the failure of a particular one of 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 portion of the physical server resources, such as computing memory, storage, and processing power. In this way, each customer instance has its own unique software stack, providing the benefits of data isolation, relatively short downtime for customer access to 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 of) data centers 18A and 18B, which may be geographically separated from one another and may provide data replication and / or failover capabilities. Using FIG. 2 as an example, a network environment and 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, virtual servers 26A-26D and 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 client instance 102, virtual servers 26A-26D and virtual database servers 104A and 104B are allocated to two different data centers 18A and 18B, with one of the data centers 18 serving as a backup data center. Other embodiments of multi-instance cloud architecture 100 may include other types of dedicated virtual servers, such as web servers. For example, client instance 102 may be associated with (e.g., supported and enabled by) dedicated virtual servers 26A-26D, dedicated virtual database servers 104A and 104B, and additional dedicated virtual web servers (not shown in FIG. 2 ).

[0026] While FIGS. 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 FIGS. 1 and 2. For example, while FIG. 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. Furthermore, 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 FIG. 2 as an example, virtual servers 26A, 26B, 26C, and 26D and virtual database servers 104A and 104B may be combined into a single virtual server. Furthermore, the present 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 set forth 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 components typical 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 reside 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 schematically 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 retrieving instructions from memory 206.

[0031] With respect to other components, the one or more buses 204 include appropriate 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, computer-readable storage medium. While depicted 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, etc. 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 or 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 (e.g., 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 disclosed embodiments. More specifically, FIG. 4 illustrates an example portion of a service provider cloud infrastructure, including the cloud-based platform 16 discussed above. The cloud-based platform 16 is connected to a client device 20 over a 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. A cloud provider infrastructure is typically configured to simultaneously support multiple end-user devices, such as client device 20, each communicating with a single client instance 102. Additionally, the cloud provider infrastructure may be configured to simultaneously support any number of client instances, such as client instance 102, each communicating with one or more end-user devices. As noted above, end users may also interface with a 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, environments 302, 304 may include customer service environments used to represent customer service infrastructure for technical support, sales, billing, and / or other groupings. Similarly, 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, environments 302, 304 may be distributed across multiple geographic locations. Thus, environments 302, 304 may include any devices accessible by a user account, including resources that may be spatially separated from one another. In some embodiments, resources 306, 308 of environments 302, 304 may communicate with each other across environments. However, in some embodiments, aspects of various environments may be provided by different vendors without communication between them. In such embodiments, resources of heterogeneous environments may communicate using a platform (e.g., a configuration management service 310 that is part of a cloud services platform and includes a CMDB 312 or equivalent configuration management data structure). 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 the properties of a service map generated based on the CIs or equivalent data structures in 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 an operation 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, via its input structure, a request to query the identity of an application program interface (API) used by a resource to access a particular vendor / provider for the first environment 302, the request being passed to the configuration management service 310 to query the CMDB 312. As another example, the client instance 102 may receive, via its input structure, a request to query the identity of a user authorized to access a particular resource, the request being 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. Furthermore, as previously discussed, the discovery process may include using a separate management or administrative device, agent, or server, such as management, instrumentation, and discovery (MID) 24A or 24B, to determine properties or attributes of resources 306 or 308 within a separate environment 302 or 304. 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 if the MID server runs on the platform 16 shown in FIG. 1 (e.g., in the configuration management service 310). Additionally or alternatively, when MID server 24A of first environment 302 is accessing second environment 304, MID server 24B of 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 rebuild 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 using translation tags 414 to generate a tagged service map 409. Generally, 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. Generally, the CI inclusion list 412 may include criteria (e.g., user-specified criteria) that indicate certain CIs to be tagged, whether based on the type of CI, the department that uses the CI, or other information that can 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 CI inclusion list 412 may indicate that switches or other CIs should not be tagged when a user does not want to monitor such CIs (e.g., CIs that may contain redundant information). In either case, processor 202 may tag the CI set of CIs 410 according to the user-specified criteria and / or 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 CMDB 312 that contains information associated with the individual CI 410. In the described embodiment, tagged service map 409 includes CIs 410a, 410b, 410c, and 410d tagged with translation tags 414a, 414b, 414c, and 414d, respectively. 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, transformation tag 414 may include value 416 that identifies the current type of the service map (e.g., "Manual ID") and key 418 that identifies the transformed type of the service map (e.g., "Tag-Based ID"). Generally, value 416 and / or key 418 may include one or more strings that identify their respective pieces of information. In this manner, service map information 418 (e.g., history information, incidents, change requests) associated with one or more CIs (i.e., those indicated by dashed lines) may be preserved even after service map 406 is transformed. History information 412 may include information such as incidents, such as change requests, alerts, and incidents, associated with CIs in service map 406.

[0041] After tagging service map 406 with transformation tags 414 to generate tagged service map 409, processor 202 may generate transformed tag-based service map 402 in block 420. In general, to generate transformed tag-based service map 402, processor 202 may repopulate or recalculate the service map based on CIs 410a, 410b, 410c, and 410d of tagged service map 409 and / or using traversal rules for CI detection. For example, processor 202 may use tag-based rules, as would be understood by one skilled in the art, to determine CIs for inclusion in transformed service map 402, such as by comparing metadata of CIs 410 with reference metadata (e.g., stored in database 312) and adding a set of CIs 410 having metadata that matches the reference metadata. In some embodiments, processor 202 may cause a GUI to display transformed tag-based service map 402 on a computing device (e.g., 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 want to maintain service maps using manual techniques to do so by linking the conversion tags to the manual service map.

[0043] As generally noted 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, a script, or other cause. Therefore, 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 to CIs, transformed tags, and / or tags of CIs made to other service maps, thereby improving the efficiency of maintaining a CMDB.

[0044] 7 is a flow diagram of an embodiment of a process 500 for updating the transformed tag-based service map 402 based on changes made to the CMDB. 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 is implemented using a processor in data center 18 via 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 translation tag 414 or that the translation 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 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, processor 202 may update transformed tag-based service map 402 at block 505 to generate updated service map 506. Generally, 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 processor 202 to determine transformed tag-based service map 402 to include the changed CIs 410 and update transformed tag-based service map 402 accordingly. Generally, service map 402 may be updated by repopulating 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, transformed tag-based service map 402 includes CIs 410a, 410b, 410c, and 410d, each tagged with transformed tags 414a, 414b, 414c, and 414d, respectively. Updated service map 506, compared to 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 updated service map 506.

[0047] In one non-limiting example 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). Accordingly, 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 with 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 is released, RAM is added to a server, or other change that affects the attributes of the CI). Accordingly, the processor 202 may tag the upgraded CI (e.g., based on the CI inclusion list), proceed to block 505, and 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 changes from the first tag value to a second tag value (e.g., "env=QA"), updating the service map would result in the first CI being removed from the service map. Other service maps configured to show CIs with the first tag value but not the second tag value would also be updated.

[0050] It should be noted that the disclosed technology may allow a user to continue modifying 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 service map 552. Generally, 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 also 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 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, transformed service map 600 includes fewer CIs compared to service map 552 of FIG. 8. In the described embodiment, 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, where the application depends on the CIs associated with icons 604, 606, 608, and 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, a converted tag may be added to, attached to, or included with 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 a 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 is 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. Furthermore, 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 containing 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); generating one or more tagged CIs by adding one or more transformation tags to one or more CIs of the first plurality of CIs based on the transformation request; generating a second service map representing a second plurality of CIs, the second service map being of a second class different from the first class, the second plurality of CIs including the one or more tagged CIs and one or more untagged CIs of the first plurality of CIs; 1. A non-transitory computer-readable medium comprising computer-executable instructions configured to cause

2. The computer-readable medium of claim 1 , wherein each transformation tag points to the first class.

3. The computer-readable medium of claim 2 , wherein each translation tag points to the second class.

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

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

6. The computer-executable instructions, when executed, are configured to cause the processor to tag the one or more CIs: obtaining criteria from the translation request indicating one or more CIs of the second class to include in the second service map; obtaining metadata indicating a type of CI for each of the one or more CIs indicated by the criteria; determining that metadata associated with the one or more CIs indicated by the criteria matches pre-stored metadata; adding the one or more transformation tags to the one or more CIs in response to determining that the metadata associated with the one or more CIs matches the pre-stored metadata; and The computer-readable medium of claim 1 comprising instructions for:

7. 2. The computer-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.

8. 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); generating one or more tagged CIs by adding one or more transformation tags to one or more CIs of the first plurality of CIs based on the transformation request; generating a second service map representing a second plurality of CIs, the second service map being of a second class different from the first class, the second plurality of CIs including the one or more tagged CIs and one or more untagged CIs of the first plurality of CIs; A method comprising:

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

10. 9. The method of claim 8, wherein the conversion 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.

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

12. The method of claim 8 , wherein each translation tag associates a change request, an incident, an alert, or a combination thereof associated with the first service map with the second service map.

13. 9. The method of claim 8, wherein generating the one or more tagged CIs includes removing a subset of CIs from the first plurality of CIs based on criteria indicating a subset of CIs to remove from the first plurality of CIs.

14. The method of claim 8 , wherein the first service map comprises a manual service map and the second service map comprises a tagging-based service map.

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

16. 16. The non-transitory computer-readable medium of claim 15, 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.

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

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

Images