The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Exploring a Low-Impact Starting Point for Service Mapping

Zach Allen1
Tera Contributor

Hi everyone,

 

We’re currently looking into how to get started with Service Mapping, but have encountered some challenges around barriers to entry, knowledge gaps, resource capacity, and scaling.

 

To simplify the process and minimize upfront effort, we’re considering the following approach:

  • Automatically create a “shell” Service Instance for each new Business Application during intake.
    • This instance would include key details like naming convention, support group, and owner.
    • Initially, it wouldn’t be linked to any Configuration Item (CI).

Once the Business Application and its Service Instance are established, and the application owner is ready, we would revisit that “shell” instance to begin service mapping. At that point, they could choose their preferred method (Tag-Based or Top-Down) and configure the mapping as usual.

 

We’d love to hear your thoughts on this approach:

  • Are there any potential pitfalls or challenges we might be overlooking?
  • How feasible is this method within the system?
  • Do you have any suggestions to improve or streamline this process?

Thanks in advance for your insights and feedback!

1 REPLY 1

Mathew Hillyard
Mega Sage

Hi @Zach Allen1 

One immediate observation is that I believe you can’t change an application service’s status to production if there are no linked CIs - at least, last time I tried to, this was a restriction. If you think about it, it makes sense as without CIs there is no “service”. You could of course work around it but you’d need some consideration about the processes, eg service desk, change etc.

 

I think it’s possible to have the top down services once ready with a dummy app CI as the entry point.

 

This is a good practice generally as with SaaS platforms for example you have nothing to discover so you will need a dummy app CI to act as the focus for Incident and change and to ensure all App Services are consistent. You could automate it as part of creating the App Service too.

 

Note I used “App Service” because those tables haven’t been renamed, but fall under the umbrella of Service Instance.

 

Happy to talk it through if you’d like.

 

I hope this helps!

Mat