We are in the process of implementing our ServiceNow Deployment, and I have the task of mapping our current CMDB into ServiceNow's CMDB. We have a particular scenario around managing business applications that I'm not sure how to handle. I would like to understand how others have handled the scenario.
The question is how do you represent business applications taking into account that the business application may have multiple lanes (e.g., Production, Staging, Development, etc.)? Our organization is used to thinking about and managing applications at a level above the lane, and each lane is "part of" the application. For example, I may be responsible for a PeopleSoft implementation. When budgeting and thinking about the product, I primary think just "PeopleSoft" - I own "PeopleSoft". However, my PeopleSoft implementation may have multiple environments or lanes that I use to manage development and patching to take things through the full development and testing process before making changes to production.
The way we chose to represent this in our existing CMDB is similar to the following:
This lets us represent it the way the business thinks about it while making it easy to see what lanes the application has and then reference the infrastructure for each lane. Doing it this way has a number of benefits, however it also has a number of issues. In particular it makes correct dependency mapping across applications more difficult. For example, does my application depend on your applications, or does my Staging environment depend on your Test environment? Or, if my business service depends on my application, is it impacted if my Staging environment goes down?
Because of these difficulties and some others, we are thinking this is probably not the best way to continue doing things as we move to ServiceNow. After discussion with our implementation partner, we are currently leaning toward NOT having a CI for the Business Application layer above and using Service Offering CIs for the various lanes. This would clean up dependency and impact mapping ambiguity. However, at the same time introduce another problem: how do we track that a set of Service Offering CIs are all part of the same business application from a portfolio management perspective? Our currently proposed model looks something like this:
A business service can be made up of one or more service offerings. Those may or may not be directly related. So, in the example above, we have multiple applications that provide the e-mail service. The CI model has those in it, but nothing that relates the Exchange service offerings together (independent of other things that make up the business service - like Gmail). We are looking at implementing a way to manage the more business view of the application in a different table - but not in the CMDB - but have not yet settled on a final solution.
I like this model better in that dependency mapping feels cleaner - you map to what you actually depend on. Additionally, the CIs that are actually represented in a change or incident are better represented (if a customer calls saying that they can't log into PeopleSoft, they are probably talking about the production instance of PeopleSoft, not the higher level concept of the "application" that I own).
I also have reservations. I am concerned that perhaps this isn't the correct use of Service Offering, or that it will cause confusion between what is a service vs. an application. An "application" had a relatively well-defined and clean meaning for us; I feel like Service Offering will be more ambiguous.
So, the question is, how do others handle this scenario (or something like it) in ServiceNow?
Thanks,
Lyle Taylor
