Best Practices - Tying Locations/Business Units and Business Apps/AppServices

[vgarcia]

Best Practices - Tying Locations/Business Units and Applications Services

Reaching out for input on what the best practices are for tying locations/business units to business application / application services. 

The goal is to be able to tell which locations (ex. Arizona State work sites)  and/or which business units (ex. Manufacturing, Transportation) use these application services / business applications (ex. Encompix/Traqx).

One application can be used by multiple business units/locations, and one business unit can use multiple application services. 

We want to be able to quickly tell what locations are impacted for a known service outage (ex. Encompix is down what business units and locations are impacted so we can follow up with them), what locations/business units are impacted when a change to Encompix application occurs. 

Any guidance is appreciated, 

Thank you,
Victoria

[CMDB Whisperer]

There are a few things to unpack here.  Let's start with the Business Application.

The Business Application is a conceptual entity that represents a specific entry in your portfolio of application technologies (commercial, home grown, etc.) that the business has selected to provide certain capabilities you need in order to operate the business.  Therefore it doesn't have a Location.  It may, however, have a Business Unit that it relates to.  The Business Unit represents an organizational entity or Line of Business -- it is distinct from but possibly related to a Department.  A Business Application can have a Business Unit.  The Business Unit itself does not have a Location but it does contain Users who have Locations.  So in theory, you could determine a list of Locations of the users in a Business Unit associated with a Business Application, but I don't think that's what you really want.  The Business Unit may be relevant to the Business Application but it does not determine who the users of the application are, or what locations are served by the capabilities that the application provides.

When it comes to determining what Locations are impacted by a Service Outage, you aren't going to get that from a Business Application.  according to the Common Service Data Model, you need to start to build out the Service Portfolio further to get this information.  Here is a quick outline of the relationships you would need.

1. Application Service (i.e. instance of a Business Application) that is having the Service Outage

2. Service Offering that contains the Application Service

3. Locations, Groups, etc. subscribed to the Service Offering

4. Catalog Items that are used to provide the Service Offering

5. Users, Groups, and Locations that are authorized for those Catalog Items

Through a combination of #3 and #5 I think you will have all of the information you need to understand who is impacted.  Again, I wouldn't look to the Business Application for this, as a Business Application is not an operational/serviceable CI.  

Hope this helps!  Please mark as Helpful/Correct if this helped you.

[s4scott]

Business applications are covered well above. I'll dive into Application Services and Technical Service Offerings. 

Both Application Service and Technical Service Offering CIs should apply to a specific instance or scope of deployment. For example, if your organization deploys a Business Application regionally, then each regional instance should have its own CI. Similarly, a Technical Service Offering can be structured to represent that service for a specific scope, such as Network VoIP Service for a facility. Generally, you don't need Service Offerings for Application Services, but they can be helpful if there is a shared support and ownership role across multiple instances. 
Many Application Services and Technical Service Offerings may not have catalog items defined. Additionally, subscriptions are geared towards individual users, and not locations or business units. If subscriptions are not a good option, then consider creating a related list to associate consuming locations or business units to the CIs. This allows you to identify the impacted/consuming locations, and does not preclude the use of subscriptions in the future.

[CMDB Whisperer]

@s4scott There are additional subscription tables on Service Offerings which are not shown by default.  

[CMDB Whisperer]

While it may be true that there are regional instances and regional offerings, it is not always the case.  How offerings are organized is highly subjective, so I would not totally rely on it to determine the Location or Business Unit, but you are correct that it may be part of the answer.