Mapping Software Capabilities

[Community Alums]

Following CSDM 4.0 and 5.0, mapping a Business Application to a Business Capability makes perfect sense. Define the product(s) you use to provide the defined capability.

Where I'm challenged however, is with end user software. We have SAM Pro installed (but not yet configured). Because of this, Discovery does not create Configuration Item records for the discovered softwares (cmdb_ci_spkg). Instead, it creates software installations (cmdb_sam_sw_installation). But the Software Installation records aren't CIs that can be used in a CI relationship record (cmdb_rel_ci).

The challenge is when enterprise architecture gets requests for new software. They'd like to be able to identify which softwares we already use to provide various capabilities like word processing, graphic design, etc. While using SAM Pro, should I be documenting our desktop software products on the Business Applications table? That feels wrong, as I've always looked at the Business Application table as the platforms we use, rather than the end user solutions. Also, that Business App record wouldn't be tied to the Software Model, so there'd be no direct correlation between the software's use and the Business App record.

Do we create Business Services for the various categories of desktop software with separate offerings for each capability? That's more in line with CSDM, but again feels wrong. We wouldn't be mapping the business service offerings back to technical service offerings or application services.

How do we map end user software to a business' capabilities so that we can easily understand what products we use at an end-user level to perform aspects of our daily jobs, and use that data to vet new software requests?

[SteveMacWWT]

@Community Alums I haven't used SAM yet so I can't speak authoritatively to it's usage in this regard, but when it comes to CSDM, I think you might be trying to make it "too perfect".

In your mentioned use case, everything you need is in the Design area of the model, and you've already hit on what architecture needs - Business Applications and Capabilities. I suggest you focus on that and get it implemented so Architecture can get what they need. 

As to goimg beyond that, the Bus Service and Offerings are as far as you need to go. While that may not feel right, the Manage Technical Services is meant to define the infrastructure that supports the applications. If there is no infrastructure that comprises the application, there is nothing to record there. And that's okay. 

Now there is some ambiguity on whether you could say there is a group that 'provides' and supports those apps. This is true, and technically correct IF you need to go there. But the commonly accepted implementation of this has been to say that those activities can be documented within the Business Service Offering. Since you offer that to your consumers you should be documenting that as Bus Services and Offerings. By extending that to Technical Service Offerings, you are adding to the data you need to manage, while adding little to no value. 

While this is just my read on it, and I applaud your desire for this to be complete, it is not necessary to cover all the areas of the CSDM for these types of use cases.