Relationship of a Bus App to a Tech Service Offering

[Chris Martin5]

I seem to have a contra-view in one area of the CSDM that I'd like someone to convince me why this doesn't make sense.   

Premise 1:  Business Apps can have relationships to Applications Services which represent the tech stack supporting the Bus App.

Premise 2:  Technical Services have relationships to App Services which represent the tech stack supporting the Tech Service Offering.

Premise 3:  Tech Services typically underpin business services

Premise 4:  Adopting Business Services at companies is a mature concept and (arguably) not critical to ever achieve

Conclusion:  Tech Service Offerings should be able to have a relationship to Business Apps where they are a supporting service for the Bus App (think, "shared service").  they would have their own App Service representing their infrastructure.

This is not in line with CSDM but, in truth, I think it should.  I want a way to represent technology shared services in the csdm and track which Bus Apps consume those.

[CMDB Whisperer]

Premise 2 should read:

Technical Service Offerings have relationship to App Services

Premise 4... well anything can be argued, but in either case I'm actually not sure what part this premise even plays in your logic.

Conclusion:  Not really understanding your conclusion.  Technical Service Offerings are what we manage as service.  They depend on instances of Business Applications, currently called Application Services but better thought of as deployed Business Application instances.  That's because those Business Applications provide a Business Capability that we are actually delivering as a Service via a Technical Service Offering.  Although the CSDM talks about a Business Application "consuming" an Application Service, in my mind that's the part that makes no sense.  Business Applications are products.  They don't actually "consume" anything. 

But in any case you are saying that Technical Service Offerings can be a supporting service for the business application.  Can you provide an example?  It seems to me that what you are really describing is a case where a Technical Service Offering is used to support another Service Offering, not to support a Business Application per se.  For example, ServiceNow is a business application, and ServiceNow Production is an application service.  IT Service Management is a Technical Service, and Incident Management is one of its Technical Service Offerings.  Now, if what you're saying is that you want to also define the Application Support, Development, or Platform Services provided by the ServiceNow platform team, then you should define those as separate Technical Services, and then define the dependencies between the various Services and Offerings, which is supported by CSDM.  ServiceNow Incident Management depends on ServiceNow Platform Services, for example.  The offerings in question may be product-specific offerings, and that's really all that's needed to represent this.

[AustinN]

So lets say you have a Technical Service that is Middleware Messaging. That would have an Offering that could be let say IBM MQ 9.1. All of the MQ devices would be tied to the Offering through a Dynamic CI group that pulls in all of the 9.1 version CIs. Now those CIs support and are are used by Application Services that role up to a Business App. That is how I would see a Technical Service being related to a Business Application (although it is multiple levels away).

[Chris Martin5]

AustinN.  I agree with your scenario of the TSO with a minor twist.  tell me if you disagree.   The MQ middelware TSO is probably a shared service in the company, used "in support" of many Bus Apps.  I want to make a relationship in SN between each Bus App that uses MQ TSO so I know all the dependencies.    I would prefer to leave the Application Services out of the picture to keep it a little simpler.

[AustinN]

I would say i disagree simply because infrastructure CI's should never be related to a business app directly according to the model. The CIs will all be used in different environments so they would be related to their respective application services, even if they are shared.