Properly classifying GitLab's CIs in CSDM

[ahbrook]

Hello everyone! I was hoping to get some feedback.

I'm currently going through by hand and determining our Service Instances here at the University - namely our Application Services. In doing so, I'm also trying to align them appropriately with either Business or Technology Management Services and their related offerings. 

I'm currently stuck a little bit on how to classify GitLab. In our environment in terms of service / offerings and business capabilities. I was hoping to get your thoughts on how you handle GitLab, and how you might approach our classification. 

At our institution, the following is true:

• GitLab is primarily used by the Administrative teams for code repository, artifact storage, and CI/CD pipeline functionality. 
• It is maintained by our central Enterprise Applications team, with access being granted to multiple College-based IT departments.
• It is NOT offered to our students or the general public (and if it were, we'd likely create a separate environment to protect any sensitive data).
• It is accessed through a singular endpoint URL, which other tools (like IDEs) access via APIs. 
• It is directly called by our Ansible playbooks for things like standing up containers, VMs, web sites, and other infrastructure. This is critical enough that we would consider it a foundational/infrastructure tier on our business criticality chart. 
• While we aren't the best at being consistent about it, GitLab's change and portfolio management functions are used by our teams. Some teams track their tasks/incidents inside it. Frankly, I'd love to see it hooked up to ServiceNow. 

I recognize that every business is going to have different definitions for their services and offerings. Heck, I'm still struggling with mapping what we do to the various education-based models out there. And all of this is made harder by how many functions GitLab can perform these days. So I just wanted to see what other people thought.

Currently, I'm leaning towards this:

• Portfolio: IT Portfolio
• Taxonomy node (Service Classification): Infrastructure
• Technology Management Service: DevSecOps Management or Code Development
• TMS Offering: Code Repository

I'm initially choosing a technology management service because GitLab provides the repository and CI/CD tools.. and it fits into the CSDM case where a Service Delivery domain element can also be part of the Service Consumption domain (because we maintain and offer it to other departments).

It is possible (and perhaps preferred?) that the Application Service would be tied to multiple services and offerings, given all the functions it supports. But for now, I'm trying to maintain a setup where each Application Service is tied to a singular Business / Technology Management Service. 

So where would you place this? 

[ahbrook]

I really do like that idea of keeping things simple. There's already enough layers of complexity in ServiceNow as-is. I think what has made me hesitant is that I am not sure if there's a mechanism to "move" something if we mis-identify it out of the gate. Our help desk (who is driving the ServiceNow implementation and owns incident/change) is most concerned about being able to associate any ticket that comes in with a service. I am worried about if we would need to recreate services/offerings in the future and get things properly linked... but I am also likely way overblowing that in my head. Also we don't have the best track record of changing things once they are in place, so I'm trying to get ahead of that curve. 

So boiling this down, keeping it simple would be: 

• Business Service: Software Development Tools
  • Business Service Offering: Gitlab - Administrative use(maybe with our URL included)
  • Business Service Offering: Gitlab - Student use (if we had a separate student environment)
• Technology Management Service: Application Administration (Management?)
  • Technology Management Service Offering: Application Administration (our team name)

And then the application instances would be our prod and test environments, the servers that host them, etc. 

[Mathew Hillyard]

Hi @ahbrook 

Are you trying to be the service manager, architect, platform owner and developer all in one 🙂

What does your organisation want to do? This gets to the heart of how you actually want to represent services and offerings. A good way to approach this is to sketch out your portfolio landscape - what to you offer to your users - and then work on which buckets those services belong. TBM is a good example of a standard you can use to define service portfolio taxonomy. It doesn't have to be complex with loads of taxonomy layers. You could just have a Business Portfolio, a Technical Portfolio, and one or two levels of taxonomy. Doing this earlier rather than later is a great way to visualise how CSDM is being implemented in your org and can help answer your questions as well as give you pointers as to where you should maybe have services, but today you don't; for example - you may realise you don'y currently have any Database Services, but you have a lead node in the portfolio ready to associate once you do. ServiceNow puts portfolio in the Fly stage but this is way too late - it adds so much value earlier on in the process.

The buildout of TMS/TMSO really depends on how you're going to support things, which is why I always ask about a customer's support model for services before we start talking specifics. A huge international enterprise might have dedicated teams for every application and CI class whereas a small org could have a single team managing all applications. This should directly effect your approach to building out the service delivery domain.

[ahbrook]

"Are you trying to be the service manager, architect, platform owner and developer all in one[?]"

... Sorta? 😄 My main goal is to make sure folks are using ServiceNow right, and that we keep an eye out for how future apps may be incorporated. The reason I'm asking all these questions is so that I can go to the decision makers and give them options for how we proceed. Many don't have time to dig into the weeds, they just want ServiceNow to do something - and there is often conflict on what that "do something" looks like.

A good example of the complexity of our University is endpoint support. Each college has their own IT department that handles deploying computers, installing software, maintaining updates, etc. They also act as the first point of contact for faculty and college staff. Meanwhile, my area maintains central resources for HR, finance, facilities, computer infrastructure, etc. So we also maintain endpoints. And then there are the students - we offer general support for any kind of problem they might have, and further support for any laptops we have loaned them or lab computers they use out in the rest of campus. So we have multiple views to approach "endpoint support" where sometimes we are the customer, sometimes we are the supplier, and sometimes we just route tickets to the appropriate area. 

With all that said, in the last year that I've been studying this, I have learned quite a bit  through all the input I've gotten here, as well as going through thought exercises and poking around to see how the various ServiceNow pieces work together. The trick I'm facing is that when I say "Portfolio," most of my colleagues are just thinking about IT services - and not the larger university services and capabilities we offer, or how a given piece of tech supports those services and capabilities. I would give anything for someone to just say "this is our portfolio," but too many cooks in the kitchen here at the University to get that. 

With all that said, I think this really is helping me navigate my way. For instance, we recently had a somewhat emergency situation where we needed to create services and CIs for our Adobe and Foxit offerings. In that case, I lumped them in as "Digital productivity" and then broke out each flavor of license we offered into its own offering. This mostly works, except people don't instantly think "Digital productivity" as a service or search term. I knew when I set it that I'd likely need to change it, or make it clearer. 

Honestly, what I'd love to see more than anything else is a complete CSDM service map. I brought this up last year, and subsequently found the data model examples powerpoint that ServiceNow put together. But while it would be overwhelming, just being able to see how ServiceNow identifies themselves and the software they use (inside and outside of ServiceNow ) would be so useful. But I know there are trade/company secrets in that, as well as money to be made by contractors and advisors. 🙂 

Again - I want to thank all of you for your input with this. Starting at how we deliver services should work, though like I said, we have many circumstances where support for an app or system could be handled by many different areas. Maybe that will change in the future. For now, just having it as an option should be good enough. 

[Mathew Hillyard]

Hi @ahbrook 

I hear you. For your setup I'd agree with the other comments to keep things simple. CSDM is designed to scale to massive international enterprise level so it needs a bit of finessing depending on your use case (and finding out who your "customers" really are and how your services are offered and supported are those fundamentals that help shape the use case).

In terms of bringing together a CSDM service map - this is what makes it "real" for people. It shows the system from customer to the lowest levels of infrastructure and (once other related supporting services are included) your technology landscape at a glance.

Start simple - get the service and offering layer right, then the Service Instances. For the actual infra this is where you must lean on app and tech SMEs and/or utilise tools such as Service Mapping. It can be long game (especially getting applicative credentials!) so take small steps to show the value as best you can.

I hope this helps!
Mat

[Fabian Kunzke]

Hi,

That would be where I would start the discussion. Then, check the following:

1) Do we have more granular, distinct user groups in our offerings? Do we have different SLAs in the offerings? Are there different owners for those offerings -> then split the BSO side into more granular offerings. In you case this could mean differentiating into a dedicated Change BSO for example.

2) Do you have independent components to provide these offerings - independent means one of the following is true: It can fail independently & must be managed independently; it is owned & managed independently; a distinct application instance (or multiple) depend on this component. -> could be in your case that you have different product owners for the components (in which case you'd also have multiple Business Applications).

3) Lastly, how do you support GitLab -> Is a separate team developing it? Do you have different support teams offering different support activities? -> Split up the TMS/TSO side.

From there you will get a good idea if that current model is complex enough to model ownership, dependency & consumers accurately.

Once these questions are answered, there are of course even more questions to go in farther depths. But the most important next step is that you do this exact exercise with other service owners - give them an introduction to CSDM, why you are modeling like that (the value, not "we have to, because ServiceNow says so), in the workshop model the most simple model and lastly. hand them the same questions. That way you can hand over the modeling to every service owner. They can maintain it themselves.

Thus, CSDM can live & grow - you are the gardener, no longer the person who pulls on grass to make it grow faster.