What level of efforts we needed for implementing Service Mapping?

[Paul125]

Hello,

Our organization currently using matured Discovery also we have Service Mapping plugin enabled but we barely never use any of it's functionalities. I am researching around how to best implement Service Mapping and steps and procedure to migrate Discovery to Service Mapping. Below are some questions I hope someone help me with. I appreciate your time.

1. We have made customization around many of our probes and sensor like MSSQL, Tomcat, Personal Computer, Apache, WebSphere and so on.. What are odds we may face to start using Service Mapping?

2. How can I differentiate b/w Discovery vs Service Mapping apart from Service Mapping can application mapping or  creates relationships b/w servers and applications unlike discovery?

3. Can we still use probes and sensors while using the Service Mapping? If yes, what will be the disadvantages?

Thanks.

[DaveHertel · Accepted solution]

Hi Paul -- lots of good questions!  To clarify, Discovery and Service Mapping (SM) are complimentary ITOM products that work together.  It's inaccurate to look at this as a "migration" because both products co-exist (both need to be present).   Its good that your Discovery environment is mature because that is a HIGHLY important pre-req.  A company should have a well-functioning Disco environment before considering Service Mapping too.  

Regarding your questions:
1. Customized probes/sensors should not have any ill-affect on SM.  No real concerns...  These probes/sensors will still be leveraged for hardware/infrastructure components, even as you implement SM.  Discovery is still needed to make SM do its thing, so existing Disco components continue to be needed.  Including such things as MID servers and Credentials, defined when you built out Disco --- these are also used by SM.

2. I don't fully understand your 'differentiate' question.  But perhaps you are asking whats the difference between Disco & SM?  If so, Disco is considered "horizontal" discovery, which I think of as more/less and INVENTORY of hardware & software... Disco is more than that, but a useful way to think of it.  Meanwhile, SM is considered "tops-down" or "vertical" discovery, of Services.  SM, instead of doing an inventory of stuff, is mapping out the key ingredients (i.e. technical components & their primary connections) to provide some service. 
    Example: Think of an airline reservation URL (as an entry point into a Service).  This reservation website has many important tech components that when all combined provide reservation service.  [think: Load balancers -> Web servers -> Database servers -> etc].   While Disco provides the inventory of machines, etc... SM provides the business perspective of "WHY" these things exist in the first place, and explicitly WHAT-CONNECTS-TO-WHAT to deliver a specific service

3. For the Discovery portion, you still use probes & sensors -- i.e. "the inventory" concept.  Disco and all its components do not go away when you implement SM.  SM leverages the data collected by Disco then SM requires PATTERNS to collect Application-level info and also to 'connect-the-components' to define the Service Map.  SM leans heavily on PATTERNS and you will want to learn how to build Patterns to 'vertically discover' Services.  Meanwhile, Probes/Sensor keep providing value to the Discovery (inventory) portion of this complex puzzle.

FYI:  Service Mapping basics video    Understanding Service Mapping docs

Below, are additional clarification provided by Disco guru extraordinaire Doug Schulze:
Service mapping:  Will utilize Hz discovery (probes/sensors) information of the server (hardware) including the running processes it found from the LAST discovery.  When it identifies a process (say apache) that is part of the map it will trigger a pattern to analyze the application and all its goodies then derive where it goes next be it from TCP connections (hz disco info) or config file instructions (SM pattern).  If a expected host is not found in a map step SM will trigger a Hz discovery to get that host in the CMDB so it can be analyzed. So your in two phases here, Hz discover doing its thing then Service mapping using the application pattern to do its analysis.
Horizontal Discovery (Hz): will use probes/sensors to do the hardware discovery then go through the “normal” application mapping that you are used to.  In the process classifiers the probes and sensors will be used unless they are on a version where patterns have replaced the oob probes/sensors which was done in phases over the last couple releases.

Any new/zboot customers on London and beyond are all patterns!  Probes and sensors are depreciated but can and are available to be used, just no more development on that front. Existing customers probes and sensors will not get replaced unless they do so on their own.. but shouldn’t until they fix a major bug with the hardware discovery.  Patterns for applications and network gear are safe to goto whenevery they (existing customers) want to.. just no on the computers…

Does this help?  Hope so! 

[doug_schulze]

Thanks, Dave.. Yeah, the "major bug" we talk about here..(in the warning).  Now fairly I could have used the word "major" a little less dramatically but its an important message when (manually) going from probes to patterns in the respective classes.

[Paul125]

Dave,

That's a great explanation. I really appreciate your time and your patience. That cleared all of my doubts. Thanks again!

[bernyalvarado]

Hi Paul,

To add in top of the great explanation provided by Dave.

In point #1) some of the main challenges that you may face when getting started with ServiceMapping often come around infrastructure setups that may be unique to your company and not supported OOB. Specially for Load Balancers, and some installations/configurations of enterprise systems. A ServiceMapping project will be successful when it is closely worked out with the infrastructure, network, security and application teams.

In point #2) as Dave stated, Discovery is a horizontal discovery agnostic of the service a CI is related to. ServiceMapping leverages a given entry point to define a service and from there map all the infrastructure that supports the service. In its most recent versions, through the information held by the Load Balancers is possible to have an up-front conversation of the services that could be mapped. 

In point #3) Dave already shared a lot of insight on this. In summary, probes and sensors will continue to run as part of your Discovery Schedules and every time there's a host discovery which gets triggered as part of the Service Mapping process. There's no disadvantages around probes & sensors, but as Dave and Doug mentioned for pattern based discovery should be the way to do any new enhancement to your horizontal discovery due to the direction that ServiceNow is taking with this.

Thanks,

Berny