Choose among the 12 CI types

Bourgos documents 12 supported CI type values. Choose the type that best explains the resource's stable operational identity. These values are not Service categories, relationship types or a promise of special behaviour for every class.

Before you start

Agree the scope needed for support and Change planning. Separate application identity, deployment, runtime and physical resource. Avoid registering transient components unless they have a stable identity and a practical maintenance purpose.

Steps

1. Identify the operational question the record must answer and search for an existing identity.
2. Choose the relevant type from the catalogue below.
3. Record environment and context, then connect the CI to the deployed Instance or supporting resources through reviewed relationships.
4. Validate the chosen classification with the technical steward and a real support/change scenario.

Deployments and application runtime

SERVICE_INSTANCE represents a concrete operational deployment, for example Employee Portal PROD. It has a paired Service Instance record sharing the CI ID and can link to a Business Application and Offerings.

APPLICATION_SERVER represents an application runtime/node, such as a Tomcat production server. It is distinct from the application portfolio identity and the VM or host beneath it.

MIDDLEWARE represents messaging, integration or middleware runtime, such as a RabbitMQ production broker. Model consumers and hosting according to actual operational reliance.

Data and storage

DATABASE represents an operational database resource or database system, such as a PostgreSQL production cluster. Establish what the record represents and how members or consumers relate before interpreting failure impact.

STORAGE represents storage resources such as an array, datastore, share or storage pool. Record the dependencies important to hosts, databases or workloads rather than assuming all co-located resources fail together.

Compute and platforms

VIRTUAL_MACHINE represents a VM hosting an operating system or workload. Keep its identity separate from its physical/cloud hosting and deployed application.

PHYSICAL_SERVER represents a physical compute host. An optional Asset record can account for purchase, custody and repair; it does not replace the CI's operational relationships.

CONTAINER_CLUSTER represents an orchestration/runtime cluster, for example a production Kubernetes cluster. Keep application deployments distinct and avoid inventing a persistent CI for every short-lived container without an operational need.

CLOUD_SERVICE represents an operationally consumed cloud service/resource, such as a managed database. Provider/region context can be useful; a commercial subscription is not automatically the same entity.

Networks and other resources

NETWORK_DEVICE represents a router, switch, firewall or appliance. Model the network dependencies relevant to service support, including real alternate paths.

NETWORK_SERVICE_INSTANCE represents a deployed network capability, such as production VPN access. It is distinct from the physical appliances that deliver it; do not assume it has the paired Service Instance subtype behaviour of SERVICE_INSTANCE merely because its name includes “instance”.

OTHER accommodates a legitimate operational resource outside the defined types. Use sparingly and document its meaning to prevent an unstructured catch-all.

Expected result

Resource classes communicate what each record represents, and shared components are represented once with explicit consumer relationships.

Important behaviour

The type catalogue is an illustrative classification, not a rigid inheritance taxonomy. CI type does not choose relationship impact mode or discover resources automatically. Use the Asset module for physical custody and financial history where appropriate.

Related guides