CMDB application dependency layout

[dustin_hux]

I am currently building a CMDB primarily focused on assets in the form of application services.   As far as the structure is concerned, I am struggling with determining how the application service and its dependencies should be laid out. Currently, I have this structure set up in my CMDB:

Business Service (tier 0)

|

Application Service (tier 1)

|

Application Server (tier 2)

|

Database Server (tier 3)

|

Database Instance (tier 4)

I am fairly certain that this is the correct way to build as CMBD as far as actual systems hierarchy is concerned, but is this the best way to do it as far as accessibility and maintaining it for the future goes?   I have seen some examples with tiers 2, 3, and 4 all clustered on tier 2, but it seems that this way would model the actual relationship the best.   Any input on whether or not this layout could work well with applications and maintenance would be appreciated.

[Sashi K1]

Hi

above hierarchy is correct per ServiceNow standard recommendation. Most of clients do follow 'Business Service' to be at top of layer. However Service Watch performs search from top contrary to Discovery performing from bottom. You may want to define a clear difference between your Service Layer and   Application Layer. Service Watch takes URL input from Business Application layer to bring relationship model across CIs in the downstream.

So consider splitting CIs between Business Service and Business Application. One Service may have service deliverable through multiple Business Applications. Sometimes with many clients there is a difference between Business Application and Application. There would be multiple applications under a Business Application. . Out of the box everything starts from Business Service to Application. But it may more sense to have a Business Service to have multiple Business Applications underneath and then Applications under each Bus App. Also consider adding Integrations in your hierarchy which connects two different Business Services.

Eg: Take Enterprise Service Management Practice

Business Service --> Enterprise Service Management Practice

Business Application --> ServiceNow

Applications --> CMDB, Incident, Problem, HR, Finance etc...

similarly use your SAP as Business Service. You may see a need of a new class between Service and Application. Application is more focussed so can't be under Business Service directly.

let me know any questions

Thanks

[dustin_hux]

Thanks for the reply.   Its good to hear some feedback.

This may need to be addressed in a separate question, but where would a mainframe like SYSB fit into this structure?   Would it take up both the application server and database server tiers or would it just replace one or the other?

[Sashi K1]

Hi

I'm not familiar with SYSB. I'm hopping its an App of type database tool with all UI and backend together?

In that case I would think this way

<Business Service that owns SYSB App>

<Business Application SYSB> --> At this layer there might be multiple Business Apps supporting above Business Service.   SYSB Bus App is one out of many!

<Application> --> I would expect to fit SYSB Application here. Its less of database but more of Application where Users primarily connect

<database> --> this is open question, if DB is part of App it can still mention it here as your maintenance team and support team is different for App and Database.

Ultimately any class is to capture information on who is

Service Owner

Business Owner

System Owner/ Assignment Group, On-Call Support, CI status, operation data etc... in addition to relationship model.

We break App into multiple layers depends operational model. In the above case, if SYSB is an App with built in DB then we split CI into multi layer if operational data is different.

Same true for Cloud Apps like ServiceNow where DB is out of scope. Only Service/BusApp/App more sense but Dagabase doesnt fit as it maintained outside of network. Same for SalesForce

Hope above helps!

[KCallaghan]

I prefer to look at this work like building a pyramid. Your Business Service is the top. That is supported by the Application server and the DB server. The DB server is supported by the DB instance.