Skeptical questions about SDLC Components

[CMDB Whisperer]

While I know that SDLC Components in CSDM 4.0 are not recommended to be used yet, I do have some doubts about the currently proposed design:

1.  If a Business Application contains SDLC components, and an Application Service is an instance of a Business Application, then it should naturally follow that an Application Service also contains the same SDLC Components as the Business Application.  However, my read of the CSDM 4.0 V2 Draft white paper is that the reverse is expected, i.e. that SDLC Components contain Application Services, as shown below:

This seems like a major logical error that needs to be corrected.  I have a client who is looking to follow CSDM and implement SDLC Components, but my advice to them at this point would be to go against the guidance of CSDM 4.0 because it is not logical.  I understand the reason for this because in order for SDLC Component to remain an optional element in the path of the existing relationship between Business Application and Application Service, the direction of that relationship needs to be consistent, otherwise the relationship itself would lead to invalid business logic.  However, the semantics (i.e. the descriptor) of the relationship does not need to be that way, nor should it be.  Rather, this relationship should use a separate relationship type where "Contained by" is the parent descriptor but the direction of the relationship is maintained. 

The result would be as follows:

2.  Several forum discussions and online resources indicate that the SDLC Component is supposed to be able to represent any component of the deployed business application, including software applications, hardware infrastructure, configuration files, etc.  But these same sources also indicate that the SDLC Component is supposed to be able to be versioned by changing its product model.  On the surface that sounds like a reasonable idea, but it begs several questions to me. 

First, how is a single CI class going to legitimately use different models with different model categories?  I know it can do that, but should it?  Normally a CI Class is associated with a single Model Category, but if my understanding about the intended use is correct, that means some of them will be associated with Hardware Models, some with Software Models, and some that are logical (e.g. Configuration Files) that may not have models at all (and thus cannot easily be classified, since they won't have model categories either.  All in all, this design seems at odds with the normally expected behavior of Models and Model Categories.

Second, let's say we are versioning a software application component of the business application, and there is a version 1 that was deployed to several instances, and then a version 2 is released to some of those instances.  Does the business application contain two separate SDLC Components, one associated with version 1, and another associated with version 2, and then the Application Service is only associated with the relevant one?  Or is there a single SDLC component that represents the latest approved version, and then we would have to query the installed software on the servers in each application service to determine which version they have?

[SebastianKunzke]

Interesting thought and I will try to follow them. 

1. Relationship type

The relationship type suggested by ServiceNow CSDM makes sense for me. I will try to explain why:

A business application "Custom Interface" could contain out of different API components. These API components will be stored as SDLC component with in the CMDB. Now let's say you bring your business application live, you can create an application service for your business application. If you now build your map manually your will probably create for every API component an own application service. Therefor you can connect the API component to the application service. So everything is fine.
BA --contains--> SDLC --contains--> AS "Api"
BA --consumes--> AS Custom Interface --contains--> AS "API"
In both ways you have a valid relationship. Please be aware CSDM is a suggestion not a hard coded framework you need 100% to follow.

2.  How is a single CI class going to legitimately use different models with different model categories?

SDLC components are probably never be discovered or from an automated data source, because of that I do not see any issues to create different model categories. However I understand SDLC components as own model class. Because my understanding it describes part of logical component of a software or infrastructure component, but not the installed software/hardware it self. This example lead me to this assumption.

3. Model Version

That leads me to the latest question, because it is a logical component maybe provided by a vendor it can be have different versions update over demand and change management. Based on that the underlying application service will be modified. 

I hope that helps, I am waiting for your response and be open for any discussion.

[CMDB Whisperer]

@SebastianKunzke thanks for the feedback.  I think the more common use case is intended to be to decompose an application into its individual components. 

Let's say we have an application that has a service-oriented architecture including a Client UI, an API Gateway, a Search service, a Registration service, and a Payments service.  If these are each deployed separately as microservices then there is a one-to-one relationship between the Application Service and the SDLC Component.  However, a similar application is architected as a monolithic application, but broken down to the same SDLC Components, then this would not make sense.  In this case, a single Application Service would appear to be "Contained by" multiple SDLC Components, which is counterintuitive at best and illogical at worst.  Rather, most would say that the Application Service consists of -- or is comprised of -- those components.  Furthermore, it's not just about the microservice components.  There are other components involved as well, including infrastructure and configuration files.  And taking these into account, I think it is evident that it is more accurate to say that an Application Service consists of these multiple components.  Language matters here, because an intuitive data model is much easier to accept and implement across the different areas of the organization.  And even in the service-based architecture scenario, I would argue that is still doesn't make sense for the logical component to "contain" the deployed instance.  Containment implies that one thing is inside another.  I do understand CSDM is a framework, but I also believe it is important for that framework to be logical and intuitive, and I do not believe that the semantics used in this relationship support the intended use cases, and would strongly suggest a different relationship type that would support an Application Service.  

Having said all of that I might suggest that there are perhaps other relationship descriptors that would be better than "Contained by" but still feel that "Contains" is not logical.

[CMDB Whisperer]

Also in response to your other feedback, thanks for the link you provided to the ServiceNow TPM documentation which is definitely helpful as it provides more definitive statements about the use of SDLC Components.  It does at least seem to support the notion that we should expect the granularity of the Application Service breakdown to be similar to that of the SDLC Component breakdown, which may lessen the significance of the example I provided for a monolithic application related to multiple SDLC Components.  As for the versioning of those components, I thought I had seen something indicating that SDLC Components were versioned whereas Business Applications are not, which is why I asked the question.  I'm not sure your response clarifies it one way or another for me but I will go back and validate my assumptions before further discussion on that question.  Thanks again for your helpful insights!

[Jim Zeigler1]

I believe most of the deployed SDLC components are already being discovered today when discovery examines the configuration for each Application running on a server. When these components are combined together into executable code that runs as a process on a server, the running process is classified as an Application, not an Application Service. If the process is running on one of the Application Server platforms the running process is classified as a specific Web Server or Application Server Class. For Microservices, I would expect the same is true(each microservice that has an internally callable API is a component of a deployed Application CI (like WAR files that are part of a Java Ear file) or if it stands alone, it would have its own Application CI. Am I missing something? It seems to me this is already supported by the existing capabilities of discovery and the class hierarchy(just add some new subclasses for specific types of platform microservices).

If patterns can't be used to remotely discover microservices, I would think an ACC-V agent would be able to query the cloud platform APIs to discover the packaging hierarchy for microservices.