CSDM implementation stages — Crawl

  • Release version: Xanadu
  • Updated August 1, 2024
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CSDM implementation stages — Crawl

    The Crawl stage of CSDM implementation focuses on establishing foundational CMDB data related to IT Service Management (ITSM). This stage targets base-system CMDB tables critical for supporting Incident Management and Change Management. It also prepares your environment for faster Application Portfolio Management (APM) setup, enables DevOps capabilities, supports Service Mapping, and facilitates Technology Portfolio Management (TPM) risk assessment.

    Show full answer Show less

    Key Features

    • Base-system CMDB tables worked on: Business Application [cmdbcibusinessapp], Mapped Application Service [cmdbciservicediscovered], Application [cmdbciappl], and discoverable Servers/Hosts.
    • Logical CIs: Some classes implemented are logical Configuration Items (CIs) not created through Discovery and should be associated with product models for product-centric management.
    • Business Application table: Stores conceptual data like your application inventory and portfolio metadata. It is not used directly by ITSM incident, problem, or change processes.
    • SDLC Component table (optional): Represents software elements of applications and infrastructure, enabling DevOps pipeline management and visualization.
    • Application Service table: Captures logical application services often identified by users reporting issues. Supports multiple deployment environments and geographies with logical lifecycle management.
    • Application table: Represents discoverable application instances created and maintained by Discovery. It is not an application inventory or portfolio and should not be manually populated.

    Key Outcomes

    • Minimum CMDB support requirements for Incident and Change Management are fulfilled.
    • Business application data is accurately placed to accelerate APM setup.
    • DevOps capabilities are enabled by populating SDLC component data, facilitating application development pipeline management.
    • Service Mapping can be effectively used for mapping application entry points due to populated application service data.
    • Foundation for TPM risk management is established, allowing better monitoring of application technology lifecycles and versions.
    • Supports identifying outdated or at-risk software through integration with APM, Service Mapping, and Software Asset Management (SAM) Professional.

    In the Crawl stage, you work on base-system CMDB tables that are associated with IT Service Management (ITSM).

    Benefits of the operations that you perform in the Crawl stage

    • The operations provide the minimum CMDB support requirements for Incident Management and Change Management.
    • Setting up APM is faster because your business application data is in the right place in the CMDB.
    • The operations build the foundation for using DevOps because your SDLC component data is populated and ready to relate to your applications.
    • Service Mapping is ready to use for mapping entry points because your application service data is populated.
    • The operations build the foundation for using TPM risk details, a capability of APM.

      The operations prepare you to manage and monitor the life cycles and versions of the underlying technologies of the business applications in your enterprise.

      The data enables you to identify outdated or at-risk software using APM, Service Mapping and Software Asset Management (SAM) Professional.

    Tables that you work on during the Crawl stage

    Important:
    Future products and product enhancements depend on the data that you prepare in each of the tables.
    During this stage, you work on the following base-system CMDB tables:
    • Business Application table [cmdb_ci_business_app]
    • Mapped Application Service table [cmdb_ci_service_discovered].
    • Application table [cmdb_ci_appl] (discoverable)
    • Server/host (discoverable)
    Note:
    Some of the classes that you implement in this stage are logical CIs. Logical CIs aren’t created through Discovery, so their Model ID values might not refer to product model (application model, service model, or software model) records. To help you to migrate to a product-centric management paradigm, each instance of a logical CI should be associated with a product model. See Auto-generate product models for logical CIs.

    Tables that you work on during the Crawl stage.

    Start by focusing on applications and the application-related data in these areas and tables:
    Business Application table [cmdb_ci_business_app]

    A business application is a base-system CMDB table that stores your inventory, application portfolio, and their metadata.

    Note:
    Because this table holds conceptual data, not operational CIs, it is not used by ITSM Incident Management, Problem Management, or Change Management processes.
    SDLC Component table [cmdb_ci_sdlc_component]

    SDLC component CI records in the SDLC Component table [cmdb_ci_sdlc_component] enable the DevOps product to provide enhanced capabilities for visualizing and managing your application development pipeline. Not all organizations use this data — this is an optional table.

    This table represents the software part or element of a larger whole for applications and infrastructure. Related material may serve as representative of developmental details. It can be used if you need to identify the stratification of a business application or digital product.
    Note:
    Because this table holds logical data, not operational CIs, it is not used by ITSM Incident Management, Problem Management, or Change Management processes.
    Application Service table [cmdb_ci_service_auto]

    The application service is typically the system that a caller identifies when they report an issue with an application.

    A mapped application service is a base-system CMDB table that identifies the related business application in use. The application service ties all the elements of the CSDM together where applications are present.

    You might have several application services representing each deployment based on the environment (development, QA, production) and location or geography (North America, Asia Pacific).

    Because application services are logical in nature, they should use the Logical life-cycle value pairs. Application services follow the same life-cycle guidance as any other logical CI.

    See Monitor the health of application services on the Application Services dashboard.

    Application table [cmdb_ci_appl]

    An application is a base-system CMDB table that represents the discoverable instance of an application: code related to a process in use on a host. This table isn't an inventory of your applications. Because of the high level of complexity involved, don't try to manually populate the application table. Discovery creates and maintains this table.

    Important:
    The application table [cmdb_ci_appl] isn't an inventory or portfolio of your applications. Don't make the mistake of storing managed application details in the application table. Those details (inventory or application portfolio objects) belong in the business application table (as documented in Design domain of the CSDM framework).

    The application might be identified as the root cause of an incident. However, if you're not using Event Management, the application might not be the initial cause.

    If you're using Discovery, applications are automatically related to their host, which provides an impact hierarchy from server-to-host applications.