CSDM example/attempt for on-prem WordPress and Drupal

[Elias2]

I thought I would take a crack at modelling our Drupal and WordPress web services under the CSDM framework. Essentially, the same team oversees these services (consultation, development and administration) for both of these offerings. How would I capture the "development" element (identified in pink down below)? Specifically, it is a technical service offering or do I capture it under the Design phase? This would be for the design of new and/or current websites.

[Fred Jonkhart]

My 2 cents.
Only Prod is business, so I would apply business service offering only for Prod application services. Business people subscribe to these offerings.
Non-Prod application services can be assigned technical service offerings which are aimed at the developers/tech people doing LCM. This is to formalize / complete the administration. I hope developers know their own stuff and do not really need this administration.

I am not sure what you want to capture with "development".

IMHO, to achieve full traceability, each CI should have a corresponding "development" element that defines a specific version, so you always know what versions of anything are running in production.
Such a development element should have links to what I call "engineering data", of which the source code is most important, to achieve full traceability from a code commit in Git to a production CI.
At the most abstract level each CI class has a potential link/reference to a product model. So I would expect that for each CI there is a corresponding product model sub-class.
Unfortunately that is not the case. The abundance of types of CI classes, are not mirrorred at the product model side. For some such as software there is a clear path, for most CIs it is not clear.

So, for software CIs you can create Software Model records (e.g. Drupal and Wordpress) and you can captured subsequent versions. I am not sure if without SAM Pro discovery of software CIs is supported to link software CI's to their subsequent Software Models automatically.

With respect to linking SN elements to development tools, this is not supported as far as I know and for which we build some custom solution.

And then there is the SDLC Component. I find it difficulty to position given the current knowledge shared by ServciceNow.

[Elias2]

Thanks Fred for you response and thoughts. I do agree with you on the Dev components. I fell in to the trap of trying to link all CMDB records for these services and thus ended up attaching those Dev components. You highlight something very important. CSDM is a foundational framework, and ServiceNow leverages the crawl/walk/run/fly methodology for it, but there is a licensing component to the higher maturity application of the CSDM. I would need to license HAM and SAM to fully leverage and correctly benefit from CSDM, but that comes at a financial cost. Most of us start off with basic ITOM just to take a crack at this framework but can eventually find ourselves held back unless we start licensing the components needed to benefit holistically from this framework.

The goal I wish to achieve with a CSDM implementation is full end-to-end visibility of all "CI" for any given service. If a dev environment is leveraged to provide product design and testing, then it ought to be captured (linked or referenced) in the model. But as you said, the framework is not there just yet.

Elias

[Fred Jonkhart]

If I had a greenfield situation I would look at Backstage / getport.io or something similar (dev portal) for getting your development stuff under control. And then somehow sync the major entities of such a portal with a ServiceNow custom sub-class under product model. Then you can leverage the CI -> product model reference.
When the CSDM product model sub-classes evolve, switch to an out-of-the-box class whenever possible.
PS did not look if someone already build some integration

[andrewrouch]

I don't agree with only Prod being related to Business apps, the non-prod environments support the development of changes and upgrades to the Prod environment and the investment in those environments must be paid by the business team that owns the application, so it makes sense to link the non-prods as application services to the business application. 

What does not make sense in the model above though is the common support team element that creates direct relationship between one application service and multiple business apps, the support teams are linked to the individual CIs and even when they are all in the same cost centre it is better to represent the application services as specific to a business application so the cost of the that service can be calculated individually.