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? 

[Mathew Hillyard]

@Fabian Kunzke 

As you say, context is everything.

I believe @ahbrook works in an educational environment (something I missed in the original post), which does somewhat change the advice as the "business" from this perspective is much more like to be technology consumers than your "average Joe" who uses Office and a few other apps.

This is why the distinction between Business/Technical is the type of consumer. This is often missed by people working with CSDM - a business service is not necessarily what "pays for" technology management services. End user services/desktop support is a classic example - business or technical? Which business service pays for networking? Or Storage? Discuss 🙂

Accuracy is key - don't bodge a solution today for convenience, only to rework later on. This is why there is a maturity model. Linking infra to business services usually occurs in Run (although the maturity model doesn't always suit every use case). Get the fundamentals right at the beginning.

This is all part of designing and implementing a complex model that requires siginificant business change. My concern with advice such as to put off TMS/TMSO until later is that it reinforces the culture that CSDM is sort of optional, or something where you can pick and choose what you want to implement. You can do this of course, but it really limits the value of what is an expensive and time-consuming exercise. It also makes selling such concepts to the business even more challenging.

[ahbrook]

Hey everyone! 

I'm super excited to see my post blow up, especially after a few months of not getting any replies. I just wanted to let folks know I am still following along, especially as we're about to take another stab at getting service definitions laid down and applied to our systems. I have just been too busy with other efforts to reply in depth to anything posted here (or my other threads). 

[ahbrook]

@Fabian Kunzke @GeoffL-Coles @Mathew Hillyard 

So I get the arguments here about over-complicating things, having definitions for business services and technology management services, and other complications. But I keep coming back to an inherent issue with GitLab: It does a LOT of things. Matthew kind of referenced this by bringing up Business Capabilities. 

So I'm wondering... Is it a candidate for treating as more of a platform, with various components under it? GitLab's website describes itself as a platform, in fact, with 10 top-level capabilities. I could see each of these as a business service.. though I personally would be hesitant to create multiple business service offerings because it would lead to confusion for our front-line staff when associating an incident. 

My biggest issue is that I'm trying to change culture around here so we use ServiceNow "properly," or at least stick to out of the box as much as we can. We come from a much more traditional ITSM, where we just call everything "Systems", associate CIs with it, and move on with our day. But this breaks down when it comes to describing just what these systems do for us. 

[GeoffL-Coles]

>Is it a candidate for treating as more of a platform, with various components under it?

Only if there is a reason to manage it like that!

Do the components/modules/apps under it have different groups funding or supporting them or have different criticality/uptime?  Business Application is the governance layer - by having it as a platform with platform modules/applications sitting under it adds overhead to the management of records and tracking/attestations. 

Create a number of 'patterns' to describe usage. You can mix and match single apps and platform/modules. 

[Fabian Kunzke]

@ahbrook I agree with Geoff. I've written an article about how I would recommend approaching the model and it is summarized by Geoff very well.

If there is no value in adding it, don't add it only to be "more" accurate.

If you manage the different functionalities of the platform in different styles, if they can fail independently or if they have vastly different user groups, you could add them. But it's more likely you can rather add additional offerings for each process activity available on the platform.

Also: You can always add more granularity. So if you notice down the road that you would indeed like to separate the platform into different components with different functionality (because they have different product owners or can fail independently), do that.

But: You can always start simple (I've lead implementations where ServiceNow was modeled as just one Application Instance because there was just one owner, a largely homogeneous user group, no independent failure & a setup where the offerings already separated the consumed process activities).