Hi,

can anyone explain the sense of the gold brick to me? I can see benefit in the idea of this, but not in the way it is done in Catalog (I tried it with 14.1)

1. In catalog I have the possibility to associate CIs to Services.

    Question: Why CIs and not Models? Every time a new CI is added to the MDB I would have to associate it to the Service.

2. When it then comes to fulfillment and I click on the goldbrick icon, APM opens and I can fulfill from inventory.

    Question: Why can I in this mask assign any CI to the request independent from what I configured in CI - Service association? I would assume, when I associate printer CIs to the "Procure Printer" Service, that I also only can fulfill this request with printers and not with, lets say Smartphones.

As it works right now, I see no sense in the CI - Service association.

And another question: Is there any way to see witch CI was assigned to witch service?

Thanks and best regards,

Markus

Any help for Markus?

Thanks

sense of gold brick

MARKUS HERGETH Apr 9, 2015 10:15 AM

Hi,

can anyone explain the sense of the gold brick to me? I can see benefit in the idea of this, but not in the way it is done in Catalog (I tried it with 14.1)

1. In catalog I have the possibility to associate CIs to Services.

    Question: Why CIs and not Models? Every time a new CI is added to the MDB I would have to associate it to the Service.

2. When it then comes to fulfillment and I click on the goldbrick icon, APM opens and I can fulfill from inventory.

    Question: Why can I in this mask assign any CI to the request independent from what I configured in CI - Service association? I would assume, when I associate printer CIs to the "Procure Printer" Service, that I also only can fulfill this request with printers and not with, lets say Smartphones.

As it works right now, I see no sense in the CI - Service association.

And another question: Is there any way to see witch CI was assigned to witch service?

Thanks and best regards,

Markus

Hi herma13,

I consider these integrations as separate and typically used for different use cases:

1. The idea behind the capability to associate CIs to a Services published in Service Catalog is that when you model a business or IT service in the CMDB (with all its dependencies on underlying infrastructure components) then this service is potentially a candidate for the consumers of services to subscribe to. Therefore it makes sense that the business or IT services in the CMDB are being associated to a published service in Service Catalog. Service Catalog can be used to track who or which business units are subscribed to the specific service.
2. The (service) asset request -> fulfillment use case is different from a service subscription use case in the way that you're physically delivering an asset to the user (consumer) of that service, and the design idea behind the "yellow brick" integration therefore is associated with models and assets. I therefore wouldn't suggest associating this type of service published in Service Catalog with a business or IT service in the CMDB, unless the customer insists on this. (Please don't get me wrong, there's nothing wrong in doing so, but it may cause more confusion...) The fulfillment process (in Process Automation) can link the asset selected (using the "yellow brick") to the change order in SDM and as such the preparation and handling of the asset can be driven through this change order.

I would like others to chime in on this use case, as there may be other and better examples.

Thanks,

John Sorensen