Business Applications, SDLC Components, and Application Services

[jna2756]

Hi

Our company is starting to look into capturing the SDLC components in ServiceNow as we start to go deeper in the DevOps module in ServiceNow. Historically, we have captured Business Application -> Service Instance (example below). According to CSDM it would be now Business Application -> SDLC component -> Service Instance.

Current state:

Purposed future state based on my understanding:

1: Are the relationships identified with (1) in the image above recommended still? If not, is there any issues of including it?

2: Should the service instances in (2) be broken down to the SDLC component level? For example: should we have "Purchasing - UI - Prod/Test/Dev "and "Purchasing functions - Prod/Test/Dev". Are there issues with breaking it down further or could we continue with out current standard?

Thanks for you time and insight

Josh

[Kieran Anson]

Hi Josh,

Yes you can keep the biz app to service instance relationship if it aids in your visibility/reporting. Just be mindful that it's additional information to maintain and if the accuracy drifts, confidence will drop.

For your other question, will you benefit from having each SDLC component represented as it's own service instance? Does the:

• Support team
• SLA 
• Criticality 
• Service commitment
• Subscribed user base 

differ? Does the granularity aid in visibility or triage when managing ITSM processes? 

If any of those are a yes, then your diagram works. If there's doubt, then it might be unnecessary granularity at this stage

[jna2756]

Thanks for the information and clarity, that does make sense from a maintainability perspective.

[Mathew Hillyard · Accepted solution]

Hi @jna2756 

1. The SDLC Component is (and I quote)

"to represent the parts of a larger Business Application / Digital Product broken down into its individually developed components."

This can be Application or Infrastructure. For Application this can include both Microservices and APIs - although there is some crossover with Digital Integration Management. For Infrastructure this is for example database or security configurations. In addition,

"A deployed instance of a SDLC Component of type “Application” would be an Application Service. A
deployed instance of a SDLC Component of type “Infrastructure” would be any infrastructure CI for
which the SDLC component represents that snapshot of its configuration details."

So this seems to suggest that the Business Application connection direct to Service Instance is unnecessary if you are using SDLC Components. This makes sense as the SDLC domain is optional - but one caution on this is that impacted service calculation and other platform features (e.g. suggested CI relationships, the Application Service Wizard) still expect and are hard-coded to use a direct relationship between Business Application and Service Instance, and indeed the v4.0 relationship (Consumes::consumed by), not the v5.0 relationship (Uses::used by). So you will likely have to preserve the direct relationship anyway.

2) I don't see any benefit to having separate components for each Service Instance as each Instance is an instantiation of the Business Application, so should be identical in terms of components.

I hope this helps!

Mat

[jna2756]

Thanks for the additional clarification. One additional question, do you believe that the relationship should be one to one or one to many; see example below. From the context you have provided, I feel like from an application perspective, it feels like it would be that one to one relationship but from an infrastructure perspective, I feel like it could be one to many.