NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: INTERMEDIATE
Assumes basic knowledge and/or familiarity of CMDB and CI Relationships in ServiceNow.
____________________________________________________________________________
As an Architect and Designer I am often asked to assist with client CMDB implementation or rework. In ServiceNow there is ambiguity with the Business Services, Business Applications, Business Service Groups, and the list goes on. I am asked a lot about what is the Best Practice for setting all of these up? How does this work with ServiceMapping? What is discoverable? What happens if I implement Software Asset Management? Shoot, why would you even want to define them in ServiceNow anyway?!
I have my take, and I thought I would pass on what my thoughts are on these. I will probably ignite a fire-storm of discussion in the process! Ah well. 🙂
First! The whole purpose of defining a Business Service in ServiceNow, and tying it to the underlying CI structure is:
- to give the ability to create Incidents, Problem, and/or Change tickets against the Business Service
- to be able to define what the supporting structure of a given Business Service(s) would be (ServiceMapping can do this automatically)
- to provide organization of nebulous collections of services provided by a group
- <<insert your favorite business service reasoning here>>
Note: It really depends our your business needs right? So, what I am trying to do here is draw a line in the sand on this stuff.
Second, definitions!
BSM Map - Business Service Management map. Diagramming application describing relationships between CIs. Business Service Management Map - ServiceNow Wiki
Business Service - A grouping of service or services that support a Business Process. ITIL v3, Business Services - ServiceNow Wiki (ITIL v2)
Business Group - A group of skilled individuals that support a Business Service.
Business Application (Business Software) - Wikipedia had the very best definition for this: Business software - Wikipedia, the free encyclopedia
Business Service — Entry Point - An IP or URL for a discoverable Business Application.
Software Package - In ServiceNow this is a normalized entry written by Discovery that describes several sub-versions of the same software.
Configuration Item (CI) - is a database entry that technically describes hardware or software for the purposes of corporate tracking.
CMDB - Configuration Management Database - is a collection of tables organized to best represent hardware and software CIs.
New in Helsinki: CMDB Health Dashboard
Network Path Discovery in ServiceNow Service Mapping
Finally, now that we have a bit of definition on what things are called we need to talk about the way in which they can be organized and related in the ServiceNow CMDB structure. I have defined six basic patterns and three hybrid patterns in use in the ServiceNow eco-systems. I have named these thusly:
1. Business Service Basic Pattern
2. Business Service to Application Table Pattern
3. Business Service to Business Application Pattern
4. Business Service to Software Package Table Pattern
5. Business Service to Revised Software Package Table Pattern
6. Service Mapping Pattern
7. Hybrid Service Mapping Pattern
8. Hybrid Service Mapping With Revised Software Package Table Pattern
9. Fully Integrated Hybrid Pattern
I will describe the make-up and uses of each. The first six in this article, and the next three hybrid patterns in a follow-on article.
So what are the actual organizational patterns here? Well let's see!
Note: With the exception of the Service Mapping pattern all relationships will need to be manually created. Also note that Business Services can tie to other Business Services. As with all manual relationships it is up to the data owner(s) to keep things up to date. Remember: The CMDB has to be the rock-solid dependable data foundation for everything else (especially Asset Management). Bad data equals undependable CMDB.
1. Business Service Basic Pattern
I put this here as this is how the majority of companies start out. Simply defining the basic Business Services and tying them with manually created relationships to their underlying discoverable CIs. Usually if a Business Application is considered it is just labeled as a Business Service.
The table described here is: Business Services (cmdb_ci_service).
2. Business Service to (Business) Application Table Pattern
This is old pattern (I implemented my first one of these back in early 2012). Here you create manual relationships between the Business Services and the Applications table. Then from the Applications table to the discoverable supporting CIs. At which point Discovery fills in the rest of the CIs and their respective relationships.
This particular pattern has basically been obsoleted. Prior to the Fuji release I was aware of a number of companies using the Application table (cmdb_ci_appl) for the purpose of segregating their Business Services and Business Applications. With the advent of the Fuji release this table was repurposed for use by Discovery to store Web Sites and Web Services CIs. This forced a reevaluation of whether to continue using the Application table for this purpose. The problem: Do you dual-purpose the Application table with two different types of CIs (undesirable), or do you move your original Application data out someplace. Most everyone I have worked with has determined that moving the data out of the Application table was the best option. This has a pain-point as it requires not only moving the data, but any relationships to the new location.
So where to? Custom table? No. The best location was to move it up to the Business Service table (see Pattern 3). The only logical place to put the Business Applications. There really wasn't any other place to go. Remember the table you choose must be extended from the CMDB table (it must have the Class field) in order for relationships to be created to other CIs.
The two tables described here are: Business Services (cmdb_ci_service), and Applications (cmdb_ci_appl).
3. Business Service to Business Application Pattern
This is another old pattern (I put one of these together for the first time in 2013). The reasoning was that the Application table was not necessarily a good fit for Business Applications without modifications; whereas the Business Service had most of the desired fields. Similar to Pattern 1, the data owner would have to create manual relationships from the Business Services to the Business Application (or Software), and then to the discoverable supporting CIs. It is easy to maintain, and straightforward to create.
This is a very popular model, and is used by several companies I know of.
The table described here is: Business Services (cmdb_ci_service).
4. Business Service to Software Package Table Pattern
Here is another old pattern. Many companies desired to be able to drill-down via relationships from Business Services to discovered and normalized software in the Software Package table. This allowed for easy referencing from the Business Service CI to a referenced list of all devices where a discovered software package was installed. Along with an easy relationship view via the BSM to the same. Counts were also provided here for each package. This particular model only works if Software Asset Management (SAM) has not yet been installed. Installation of the SAM plug-in changes the table structure, and where the data is being stored by Discovery.
The three tables described here are: Business Services (cmdb_ci_service), Software Packages (cmdb_ci_spkg), Software Instances (Installed On) (cmdb_software_instance).
5. Business Service to Revised Software Package Table Pattern
With the advent of Software Asset Management (SAM); the SAM plug-in reworked the structure for installed software count data. This had an unfortunate side-affect in that Pattern 4 was suddenly bereft of the related list Installed On data. The Installed On (Software Instances) table data was migrated to a new Software Installs table (there is a warning to the affect in the SAM Wiki, btw). This effectively rendered the pattern unusable! The difficulty here is that even though the Discovery Model table is labeled as a CMDB table it is actually a stand-alone table and does not inherit from the CMDB structure. This makes it impossible to move the relationships from the Software Package table to the Discovery Model table. The fix? Ben Sweetser (bsweetser) gave me the clue I needed to bring Pattern 4 back to usability (remember you can't un-install a plug-in); while still keeping everything the new SAM way (see: Software Installs not listed in the CMDB?). Create a new System Definition -> Relationship between the Software Package and Software installs table; cutting the Installed On table loose in the process (no longer relevant right?).
In my part 3 article, of this series, I provide a lab showing how to implement the Relationship between the Software Packages table and the Software Installs table.
Note: There is a problem with the SAM plug-in in that it does not, on the Computer and Server (et. al.) CIs, remove the old Software Instances related list tab, and replace it with the new Software Installs related list tab. You will need to do this manually instead.
The tables described here are: Business Services (cmdb_ci_service), Software Packages (cmdb_ci_spkg), Software Instances (Installed On) (cmdb_software_instance), Software Installs (cmdb_sam_sw_install), and Discovery Model (cmdb_sam_sw_discovery_model).
6. Service Mapping Pattern
With the Geneva release we have the integration of ServiceMapping into Discovery. We now have two approaches to discovering CIs. ServiceMapping gives us top-down from a Business Service entry point (Web Service, Web Site, Active Directory Server, etc.) to discovery of the supporting infrastructure. While Discovery gives us a layered approach by scanning ranges of IPs, and building up a picture with multiple scans of different inter-relating ranges. ServiceMapping has a different separate BSM structure (this is different than what we had with ServiceWatch imports, but mimics what you had inside of the original application). Interestingly the ServiceMapping table structure inherits from the original Business Service table (makes sense). With the pure ServiceMapping approach everything is "discoverable."
The two tables described are: Business Services (cmdb_ci_service_discovered), and Business Services (cmdb_ci_service).
That is it on the basic Business Service patterns. In my next article (part 2) I will delve into the three hybrid models which are combinations of these six basic patterns. In part 3 I will post labs on how to implement the Software Package relationship to the new SAM Software Installs table, and how to add the new SAM Software Installs related list tab to the Computer CI Form.
Steven Bell
For a list of all of my articles: Community Code Snippets: Articles List to Date
Please Share, Like, Bookmark, Mark Helpful, or Comment this blog if you've found it helpful or insightful.
Also, if you are not already, I would like to encourage you to become a member of our blog!
6 Comments
