Business application relationship with CIs

[Yuri Yoshinami]

Is it ok to add CI relationship with business application(cmdb_ci_business_app) directly with Infrastructure CIs, such as Windows servers and Linux servers?
When seeing the screenshot below, it looks "Business Application" has direct relationships with only "Information Object" and "Business Application" and "Application Service".  

I have tried with my personal instance adding CI relationship with business application and CIs, such as windows servers and Linux servers, and it worked as the third screenshot. I am curious about why "Business Application" "Depends on" "Infrastructure CIs" are not in the prescribed relationships below?

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/csdm-implementation/concept/ci-relationships.html

[Stig Brandt]

Wow, well  spotted Erik, thanks for sharing, adds more to the confusion to the topic 😉

[Yuri Yoshinami]

Thanks, @erikbartholdy  @Stig Brandt  

Yes. I also have read that sentence before and got confused.

Our customer's requirements is managing the data of business application only, and not thinking about implementing Discovery on this phase. Discovery will be in the next phase.

Therefore, I was thinking to importing data into "Business Application" for the Foundation and Crawl phase. But I came to think that we need to have data on both "Business Application" and "Application Service" at least with registering data on manual, so that MID can create a relationship automatically when we implement Discovery in the future.

"Application" and "Infrastructure CI" should be discoverable when implementing Discovery, so we should not touch on this phase?

Correct me if my understanding is wrong.

[Stig Brandt]

Hi Yuri

This refer to my 3. point, impact on other modules.

Not having Application service, will not make you able to have the right tickets on INC/PRB/CHG and other modules, as this is an Application Service -> Affected CI's.

With or without Service Mapping/Discovery, you will still need to have the Application service, they can be used later on, when implementing Service Mapping, pls be aware that discovery is horisontal - and is only doing discovery of your CI Components not related them to your application, here you need Service Mapping (that do the vertical application discovery) or do it manually.

So not really seeing any good arguments going down that road you try, no matter what a whitepaper from ServiceNow tells you, sorry, just my 2cents.

[Shambo]

Hi Yuri,

If you refer to the white paper, 

Business Application

A Business application represents all software and infrastructure environments (Dev, Test, Prod) configured to provide business functionality (cmdb_ci_business_app)

Key Details

• Inventory of Application (Portfolio)

• NOT an Operational CI

• NOT used in Incident, Problem, Change (IPC)

• NOT Version specific

• Contains Meta data about the Business Application

Application Service

An Application service is a service type that is a logical representation of a deployed application stack. (cmdb_ci_service_auto) .

Key Details

• An Operational CI

• Focus in Incident, Problem, Change (IPC)

• Unique Instance of an Application

• May be created per “Environment” ex. Dev, QA, Prod

• May be created per region

• Creation Methods: Manual Mapping, Service Mapping with Entry Point, Tags, Dynamic Query

Based on above definitions, it is always recommended to go with Application Service as you can categorize which Business Application instance it is referring to (like Prod, Dev and Test).

To create Application Service, you can use Service Mapping (comes as separate subscription) or use Dynamic CI group to group Infra CIs together under same Application Service( or manually relate Infra CIs to App Service based on your use case) and relate Business Application to Application Service.

It is as per CSDM best practice.

Thanks,

Shambo Maitra

[CMDB Whisperer]

As others have pointed out in different ways, it's not whether you can do it, it's whether it makes sense to do it. The purpose of CSDM is to provide a prescriptive way of defining and relating CIs so that we can consistently model infrastructure, applications, and services in a common convention.  And this part of the equation is simple.  A business application represents the technology that an organization has selected to provide certain capabilities that are necessary to do business.  Only when it creates an instance of that business application has anything been realized as a serviceable configuration item.  Until then, there is no dependency.  The application service is the glue that binds all of the installed applications and infrastructure that are used to run a specific instance of that business application.  And you can (and typically do) have multiple instances of an application (e.g. Development, Test, Production).  So that's where you want to define those dependencies. 

A server is part of an application service, which is an instance of a business application.  The business application provides certain capabilities to the business and does so by using certain kinds of information.  The capabilities and information that a business application uses are typically common to all instances, so the business application is where those relationships are defined.  But the business application only has dependencies on a Production server via the Production instance, i.e. the Production application service.

I and others have often said that Application Instance would be less confusing to people than Application Service.  And Instantiated As::Instance Of would be a more intuitive relationship type than Consumes/Consumed by.  And thinking of it that way can still be helpful, because in reality that's still what we're saying, and thats how we often speak.  ServiceNow Production is an instance of ServiceNow.  ServiceNow is the business application, and ServiceNow Production is the application service (or instance).