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]

I think you've misunderstood. At no point did I say Business Applications are not required. Gitlab is clearly a Business Application. I was talking about building out of instantiations of Business Applications - Service Instances - which was what the OP referenced.

Part of the Crawl phase is linking infra to the relevant Business Applications and a key consideration is how these Infra CIs are identified and created. For true SaaS where you have no access to the underlying infrastructure, what's your service map? There's nothing to discover, but a Service Instance cannot exist without at least one child CI, so how does the Application CI get created? ServiceNow is a prime example - customers have no access to either the application or database servers so what's the service map?

[Fabian Kunzke]

Thank you for adding your thoughts on the TMS & TSO!

From a pure model perspective, I 100% agree that this is the correct modeling per CSDM definition.

What I don't agree on is that there would be no room for a BSO. A BSO is also offered to the business. And depending on how they use GitLab (and this is something I can only make an assumption - needs to be verified):

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.

Incident Management and Change Management are - in most cases - business processes & reflected as business service offerings. If this is the case, there would be TSOs (e.g. deployment automation / CI/CD) & BSOs (Incident, Change, DevOps). As I've written in my previous response it is a simpler approach (especially for other teams) to see what they provide to other teams as BSO consistently. Yes, this would result in just BSOs. Yes, this is not 100% in-line with the definition of CSDM 5.0. But it simplifies the model to a point where the discussion becomes less complex and the result becomes more governable.

Ofc. if you are required to separate strictly, you would require TSOs and BSOs.

At the end of the day, TMS & BS are a point of definition and company scope/culture. It is important to have a clear definition. And looking at the current discussion, there is no clear right/wrong. On a technical level, this differentiation is actually quite minute (mostly resulting in separated catalogs).

TL;DR Just BS & BSO -> technically not clean, but easier to maintain & explain; Both TMS & TSO -> technically correct, but harder to maintain & explain.

Again: This is just my opinion. And depending on the industry, context & maturity either way is reasonable. 

[ahbrook]

To add a bit of clarification: 

A couple of our teams use GitLab's issue tracking and task tracing functionality to keep notes on code work in progress. We often link that back to incidents/service requests that we get through our other ITSMs (mainly ServiceNow, but it's sadly not the only one).  The teams that do this do a mix of both operational administration (break/fix, maintaining servers, etc) and development (writing integrations, websites, camel routes, etc). They rarely, if ever, interact with our students. Instead, they work with the various colleges and administrative departments. 

[GeoffL-Coles]

BSO pays for it. TSO fixes it. They can be the same person (particularly for technology owned applications). I like both to be mandatory - a clean list to the finance people (for renewals) and another clean list to the security people (to send late patching notices.) 

But there are really no right or wrong answers - just solutions that work for your situation. 

[ahbrook]

This may be one of the simplest breakdowns of how to consider the offerings I've heard yet. 🙂 Of course, it doesn't help when we get to University-wide situations where multiple areas/budgets pay for things, but those cases are relatively rare.