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?
