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? 

[Fabian Kunzke]

Hey,

What you've come up with, is a classic dilemma of CSDM and what counts as a "business service". With CSDM 5.0 this has become a bit more convoluted. So let's start with the "safe" option of modeling it first:

Modeling it as a BSO:

Your team supporting the DevOps infrastructure (or e.g. administrative activities) should be the TMS itself. What you describe as "being available internally" would be a BSO.

Why?

Exactly as you've said. The DevOps pipeline won't be an integral part of operational dependencies for other application services (you could model it, if you wanted to), but teams can still interact with it. More prominently, the different functionality offered through GitLab (change management for example) is indeed another BSO you are offering to your customer (albeit that customer being internally only).

See it like this: TMS & TSO are used to describe how you keep the service running, while BSO describe what you offer, to whom and how it is made available. So if someone opens an incident (very strictly speaking), they should only be able to open an incident for the service they consume (BSO).

Modeling it as TMS/TSO

Now that said, your solution will be properly modeled, IF you are consistently separating "internally" consumed service offerings from "externally" consumed. However, this is not actually the qualifying characteristic of technology services. It is rather defined by the consumer (Technical Consumer).

If you want to make sure to model it properly as TMS/TSO, you will need to start with a clear definition first on:

- Who/what is a business consumer?

- Who/what is a technical consumer?

If you want to skip making CSDM complex now, i'd suggest to assume anyone is a business consumer. Which does not mean, everyone can request everything. But it allows you to ignore complexity for now and keep modeling pretty straight forward:

- How do we support it -> documented in the TMS/TSO

- How/what do we offer -> documented in the BS/BSO

For the modeling, this will allow you to hand over the definition of this to every team. Each team can tell you, how they support their things & how they offer it. What teams may not be able to tell you is who exactly is consuming it/how it is consumed.

Now the final question would be, why switch to "your" model (which would be more accurate btw.). This is needed in cases where:

- You are required to have exact cost/effort tracking

- Where your cost effectiveness is measure (effort to be billed vs. effort internally spend)

- Where you are working in a multi-provider setup (e.g. multiple partners working on your instance to support processes)

- Where you have an extensive separation between business end consumers (e.g. leadership) and technical consumers (you)

If you are required to make that switch in the future, both BS & TMS & BSO & TSOs can be reclassified with some effort later on. This has the only downside of some performance analytics reports with historic measurements not lining up when the switch happens.

In short:
If you do not need that strict separation within CSDM and only need it on the service offering level (who is this available for), i'd recommend to stick with BS & BSOs for internal services to skip the additional complexity.

If you are required to have this in place, your definition is accurate & the more exact definition - but will come with more administrable overhead.

IN ALL CASES:

Make sure to spread the knowledge on how to model this to service owners. They need to keep their stuff up to date or everything will be outdated soon after.

Regards

Fabian

[Mathew Hillyard]

Hi @ahbrook 

The Business Application identifies who makes the software product, its architecture, user base size etc. It also identifies the Business Capabilities it supports. Can you align GitLab with any business capabilities relevant to your organisation (if you're using them, of course)? It's likely that it might be a struggle since basic DevOps pipelining and a code repository don't really lend themselves easily to regular Business Capabilities (unless you are a software development organisation or similar).

Therefore it's more likely that GitLab is relevant for people building services - one example of a technology consumer - and therefore in your example it's correct that your GitLab Service Instance(s) should be linked to at least one Technology Management Service Offering. Whether it gets its own Service Offering depends on your support model, how granular you want to go, and what standards you have in place in the rest of your portfolio.

What I really don't recommend you do is create a Business Service Offering for it. GitLab does not fit the bill to directly relate to a business-facing service from your description of its usage and therefore makes no sense and will only require rework in future. CSDM is complex enough without adding to the confusion; it's a standard that has some flexibility but also comes with many inviolable definitions and rules, so wherever possible try to reflect the reality of what something is or does - even if that reality is sometimes representational rather than strictly "real" - for example, creating a dummy Application CI for a SaaS application that has no discoverable infrastructure. 

I hope this helps!
Mat

[GeoffL-Coles]

---

- for example, creating a dummy Application CI for a SaaS application that has no discoverable infrastructure. 

I disagree. I think saas's that are used in business processes (like gitlabs) have to be a business application. Business applications are the 'governance' entity. A SaaS shouldn't just 'pop up' in an organisation. Someone should plan/assess if it is the right product (gitlab, github etc), what is the contract & SLA (will you monitor the SLA), what data is being sent? Will there be a SSO integration - if so there needs to be a design. Who owns it? How critical is it to any business processes? Do the DR/availability/backups meet the criticality requirements? All these questions need governance and a single place to store the answers to these things - which is the Business Application entity. 

[Fabian Kunzke]

I would like to add to this to be precise:

Any sort of application managed within the business to directly or indirectly provide a business service or process must be governed within a business application. This includes applications which are planned to be used in the future - as you stated, this is the reason why it should not just "pop-up".

Business applications are in the "Design" domain for a reason. This domain - per definition - must at least include anything operational, and should include anything which was or could be operational in the future.

And to go even further: CSDM is explicitly designed to forgo dummy records. There should not be any dummy record. Abstract objects where not all details are maintained yet? Sure! Reducing the scope to only production environments first to add non-production later? Sure! Dummies? No no!

At least give it a unique name and an owner. That's the bare minimum. Otherwise there is no reason to do service modelling.

TL:DR -> I 100% support Geoff in this argument.