Question on Business Service name uniqueness

[Tomko]

There is a business rule that prevents two business services from having the same name.  However, since the same application service can exist in multiple environments (Dev, QA, Production, etc), this rule causes problems.  I would prefer to call my service "ServiceNow" rather than "ServiceNow QA", "ServiceNow Prod", etc.  

I realize that this can cause problems when displaying the service on a form or report (you'd have to also include the Environment field), but other than that, is anyone aware of any negative repercussions as a result of disabling this rule?

[SanjivMeher]

But you can have just one record for ServiceNow and link it to multiple environments instead of creating multiple business services.

[Tomko]

True, but I want to relate the appropriate servers for each environment to them. Still technically doable, but not desirable.

[SanjivMeher]

I think it will create confusion and you will end up with lot of task records mapped to wrong CI. In future, if you have a integration, you may have to write specific code to chose ServiceNow for Production as CI while create application

I would rename them ServiceNow Dev, ServiceNow QA, ServiceNow UAT and ServiceNow. 

Also I would put it under application instead of business service. Because Business service has a different definition. It is a stream or service you offer, such as insurance, reinsurnace, corporate etc.

[jonathonbarton]

I agree with sanjivmeher. I think you're creating a lot of work for yourself or your successor down the road. 

"I don't want to do it that way" is the second worst reason to do something non-stock. 

The worst reason, of course, being "Because someone else (did bad thing) long ago in the past, and That's Why We Can't Have Nice Things". 😃

I'm presuming you're working in the CMDB space, and I'm wondering if you're at the maturity level (Service Mapping-wise) to have Business Service in your CMDB. 

"Email" is a Business Service, while Outlook, O365, Exchange Server (the software), The Exchange Server (the actual physical or virtual box that's running Exchange Server on it) are all components of the "Email" Business Service. IMHO, if you don't have a handle on all the other bits related to a business service, then there's no reason to have the business service defined yet - at all - because you're not going to derive *action* from it. 

Once you've got all the lower, more fiddly bits, lined up with a good ServiceMap, THEN you're ready to delineate your Business Services! At that point, you can take action! 

Example: 
CHG1000023
"We're doing emergency 'Hard Down' maintenance on CH_EXCH_SRV01 and CH_EXCH_SRV02 at 6pm tonight"
Affected CIs = CH_EXCH_SRV01 and CH_EXCH_SRV02

Your Mature ServiceMapping then marks ChoiceExchangeServer (the software with failover) as being in Maintenance Mode starting at 6pm.

THAT, in turn marks the Email Business Service as being in Maintenance Mode from 6pm onward -

...and THAT triggers a notification to all users with an email address in the system that Email will be down from 6pm onward. 

Until you're at that point, the Business Service doesn't matter. Just put the INC or CHG against CH_EXCH_SRV01 and CHG_EXCH_SRV02 and call it a day. 

Also, Business Services really should reference PRODUCTION systems only - since you (ostensibly) never offer Services to your Customers (internal or external) from SubProd instances, and a SubProd going down never triggers a Service Outage.

So, for Business Service, sub-prods don't matter. They only matter from a CI perspective at the Hardware and/or Application Software level, but even then ONLY if you want to do CMDB auditing and remediation on them.