Business Services are a significant differentiator and feature of the SL1 platform. Sl1 has 2 types of service models, the 3 Tier consisting of Business, IT, and Device Services – and the N-Tier offering greater tiers of service models. Both 3 Tier and N-Tier models ‘end’ in a Device Service where actual SL1 devices drive the Health, Availability, and Risk status reflected in the service structures. For more information on Business Services in SL1, reference: https://docs.sciencelogic.com/latest/Content/Web_Monitoring_Tools/Business_Services/business_services_intro.htm
A challenge presented in defining N-Tier models is that multiple tiers can be defined in a model then published, the design of that model dictates the service type names but any service added to the published model will be categorized as ‘New Service’ by default. The categorization of a tier is not impactful to how it operates but can have a downstream affect ease of administration, reporting, and visualization in dashboards. Having a disciplined naming convention for services (as in many other areas of the platform) will save time, effort, and complexity in maintaining the system overall.
It is not uncommon to change an approach or realize a new tier is needed to deployment of an N-Tier structure. The thought occurs often after the model is published and work has already gone into defining structure, policies, and populating Device Services when it is realized another tier or even branch is needed. That’s where this best practice focuses.
SL1 makes it fairly easy to create another tier in an N-Tier structure, simply edit a service higher in the hierarchy and under ‘Services’ another tier can be added as a ‘Service Group’. When a new Service Group is added, it only needs a name (highlighted in a red underline) and will default to ‘New Service’ in a pull-down menu next to the name.
The Service Type pull down menu will have types already defined within the model or previously created. You can type in a custom service type for the new service tier and once saved, it will be available in the pull down for other services.
The best practice of naming service types will be important when administering other features of the system such as dashboard, where choosing what services are displayed within a dashboard can be based on Service Type – making it efficient to create a dashboard showing all Location based services as an example. When using that criteria, as new services (locations) are created, they would automatically appear in the service-based dashboard without additional administration – IF the service type equaled ‘Location Environment’ as in the example above.
This discipline will also make it much easier for an administrator to audit service creation, using a filter on the Business Services page to search for ‘New Service’ and instantly know something was created and correct it to best practices and ensure it ‘fits’ within the approved model. The SL1 N-Tier service structure capability can facilitate a great user experience in a complex IT environment, but with great power comes great responsibility! Administering very large models (some environments have models 30 tiers deep totaling 1000’s of services) can be complex but using best practices around service naming, descriptions, tagging, and importantly Service Types can make it significantly easier.
Moderator