How are people tracking APIs, Services, Websites in their CMDB?

[Eric_Gauthier]

How are people tracking APIs, Services, Websites in their CMDB? These are for internally (to our company) created.  Did you create a custom class or use an OOB class?

If you created a custom class, what did you name it and what kind of things are you tracking? 

I am having a hard time finding information for this, and this seems like information a lot of people would be tracking. 

Thanks,

-Eric

[CMDB Whisperer · Accepted solution]

The best way to answer this is probably to look at it from the perspective of the Common Service Data Model (CSDM), and specifically CSDM 4.0.  Let's take them one at a time.

First, the basics.  A Business Application represents software that was developed or purchased to meet a particular business need or capability.  And an Application Service is a deployed instance of a Business Application.  Let's say you choose to use a Business Application called MyReservations to handle your corporate resource scheduling.  You deploy two Application Services, one called MyReservations - PROD and one called MyReservations - TEST.  Both of these are instances of MyReservations.

Now let's say that there is a distinct piece of software that handles the API layer so that other applications can integrate with your resource scheduling, and this is called MyReservations API.  It is hosted on a separate server so that it can handle API calls from consumers.  We can break down the Business Application into two separate component Business Applications: MyReservationsWeb, and MyReservationsAPI.  So that's three Business Application CIs related to one another.  And likewise, we would break down the Application Services in a similar fashion.  MyReservationsWeb - PROD and MyReservationsWeb - TEST for the Web tier, and MyReservationsAPI - PROD and MyReservationsAPI - TEST for the API component.  Because these are all different instances of different component application services, each has its own service map and dependencies to the underlying infrastructure (Applications, Databases, Servers, etc.)

Within each Application Service in the the Web tier, we have distinct Application CIs (i.e. installed software that runs as a process) on dedicated Servers, and which connect to specific Database Instances, which in tern may run on the same Server or a separate Server.  Within the API tier, we have a similar model -- but the main difference here is that the Application CI that runs in order to accept incoming API calls uses a different Application (or Web Site).  And rather than connecting to a Database, it is probably just sending data to the main Application Server that is running on the Web tier.  Still, at this level, within the Application Service (the instance of MyReservations), we're talking about the same basic thing.  An Application CI of one kind or another, running on a Server.

The last component of this is brand new to CSDM 4.0, which describes the application development component of the Application.  Each component, the Web Server and the API, also can have a respective SDLC component which represents a uniquely developed, tested, versions, and released piece of software, represented as a Software Model.  It can also be tied back to the specific source code, version control, system requirements, and even go all the way to the projects, and the demands that drove the development.  This is in line with a move towards integrating DevOps into the CSDM. 

Note here that even if you deployed your API by compiling it to a library so that it can be installed on individual computers, you can still start from the same SDLC component.  The only difference is how it is deployed and accessed.  In the first scenario you run the API as a Service on a specific Server where it can accept incoming API calls; in the second scenario, you compile the code as a software library and install it on individual computers, where it can be Discovered (e.g. by Discovery or SCCM) as a Software Installation, and mapped to the same versioned Software Model.

I hope this helps paint a full picture. 

Please mark this answer as Helpful and/or Correct Answer if this addressed your question.

[Eric_Gauthier]

Wow, thank you for taking the time to really break it down like that.  That was very helpful indeed. 

-Eric 

[Vera]

Tera
Thank you for your reply.  If I was interested in creating a table or utilizing one that is OOB (if available) can you provide suggestions for this route?

[upgradeyard]

Tracking APIs, services, and websites in a Configuration Management Database (CMDB) can vary depending on the specific CMDB tool being used and the organization's requirements. While there is no single correct approach, I can provide you with some general guidance and common practices.

1. Using an Existing Class: Many CMDB tools offer predefined classes or configurations that can be used to track different types of assets. It is worth checking if your CMDB tool provides any out-of-the-box (OOB) classes specifically designed for tracking APIs, services, or websites. These classes may have fields and attributes tailored to capture relevant information such as endpoints, versions, owners, dependencies, and documentation.

2. Creating a Custom Class: If your CMDB tool does not have a suitable OOB class or if you need to track additional information beyond what is provided, you can create a custom class. The name of the custom class can be chosen based on your organization's naming conventions or the specific purpose of tracking APIs, services, or websites. For example, you could name it "InternalAssets," "WebApplications," or "ServiceCatalog."

When creating a custom class, consider including the following types of attributes:

- General Information: Name, description, unique identifier, owner, department, and creation/update timestamps.
- Technical Details: URL/endpoint, version, protocol, programming language/framework, libraries, and supported methods.
- Dependencies: List of other APIs, services, or websites that this asset depends on or is dependent upon.
- Documentation: Links to relevant documentation, API specifications, user guides, and release notes.
- Security: Authentication/authorization mechanisms, encryption, access controls, and security assessments.
- Performance: Response times, throughput, availability, and any performance-related metrics or monitoring data.
- Change Management: Change history, release dates, planned/unplanned outages, and related change requests.

Remember to align the attributes and fields with the specific information you want to track, as well as any integrations or reporting requirements you may have.

Additionally, you might want to consider establishing relationships between your custom class and other existing classes in the CMDB. For example, you could link APIs to the applications they belong to, or services to the infrastructure components they utilize.

It's important to note that the exact implementation and naming conventions will vary based on the CMDB tool being used and the specific needs of your organization. It's recommended to consult the documentation and best practices provided by your CMDB tool's vendor or seek guidance from your internal IT or configuration management teams.

For more information check this yardgearsguide.com -