Rationale
The creation of a Business Service Map requires that there be a logical and easily communicated taxonomy that is both structurally sound as well as flexible to handle both known edge cases as well as unknown future cases.
\IT SERVICE (Note: This is a generic service like Storage or Email)
└───Application (This is some specific way of delivering the service RSS, Exchange, …)
├───Application (Note: This application may have a different Primary Service)
├───Database (Including sub types like “Exchange Database”)
│ └───Server
├───Module
└───Server
├───Network Device
│ └───Network
├───Rack
│ └───Datacenter
│ ├───Computer Room Air Conditioning Unit
│ ├───Condenser Cooler
│ ├───Dry Cooler
│ ├───Generator
│ ├───Heat Pump
│ ├───Power Distribution Unit
│ └───Uninterruptable Power Supply
└───Storage LUN
└───Storage Device
└───Rack
Note: Applications all have one and only one Primary Service
Note: CIs that are not Applications or Services have one and only one Primary Application
Note: A special CI Class (and its subclasses) of “Cloud …” (Cloud Application, Cloud Service, Cloud Server, …) may be used in the taxonomy at any location.
With our taxonomy we go down each branch of the tree until we dead end, or come to an object that causes a loop.
So, from a service perspective:
Storage Service
└───Storage Application (Say RSS)
└───Storage Device (Say Newton.its.yale.edu)
├───Storage LUN (Say \ifs\data\0\someshare)
└───Rack … (which ties back to Datacenter, so we stop here and just create the relationship)
The Business Service Map is a graphical depiction of the relationship between Configuration Items that assists in understanding the configuration of services and applications. It can be used to evaluate current state as well as to understand the impact of change or incident.