CSDM Relationship Question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-04-2023 08:42 AM
I question two of these. Should they be reversed?
Doesn't a business application consume an application service? I would also think that an application service would consume a SDLC component, not the other way around.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2023 07:37 PM
The explanation I have heard for "Business Application Consumes::Consumed by Application Service" is that performance statistics for the Application Service are consumed by the Business Application. The Business Application rolls up the performance metrics of its supporting application services to quantify the effectiveness of the solution. Bad performance could result in efforts to fix or replace underperforming application services.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2023 07:57 AM
Yeah I've heard that too. That's very meta. Consuming data about the performance of a thing isn't the same as consuming the thing. It sounds like a rationalization to me. Seems more likely that they just didn't want to have any kind of "Service" without something that "Consumes" it, which I can understand, but that argument goes away when they ultimately rename this class to "System". Are we really going to say that Business Application "Consumes" a System? Why not actually use something more intuitive like "Deployed to" or "Instantiated by"? Hopefully this will be corrected in favor of a more intuitive model.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2023 08:19 AM
That would depend on how "System" is defined. If we go way back, a computer or a server was "considered" a system. Today we can consider a system a group of "things" (processes, components, etc) that come together to provide something. Alabama has a good football system. Others may say, Alabama has a good football program. This means system and program are synonymous (in this regard). Program can be replaced with Application. Many places I've worked, Applications and Service are synonymous. Depending on your audience, application, service, system and program can all mean the same thing. To bring in more muddy waters, offerings and capabilities can be the same.
I've seen definitions for some of these things but I don't think I've seen one for all of them. Clear definitions are necessary when talking to people that don't work in ServiceNow. I often times find myself using definitions rather than words when talking to non-ServiceNow oriented developers and PMs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2023 08:26 AM
The context of my comment is that in CSDM 5.0 they will most likely be renaming Application Service to System, which makes more sense in that it includes Dynamic CI Groups which are not Applications.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-27-2023 11:52 AM
@CMDB Whisperer - your points make a lot of sense - wording/language matters. If you changed the relationship language to what you suggested: SDLC Component ---deployed to---> Application Service, I think it would then support both cases where either multiple SDLC Components are deployed to a single Application Service or the case where you may have multiple separate deployments (Application Services) for multiple SDLC Components. Or some case in-between. I agree with the comment that perhaps the CSDM model did not intend any differently, but the current language leads to unnecessary ambiguity.