Poll - Balance of MP to Content in MP

Brian_Wiest

Wondering what people follow out there.

Is is better to make more Management Packs with a few items contained. ie Request Offerings, or better to have one large MP with most of the request offerings contained. 

Adam_Dzyacky

It's kind of the like the old group policy school of thought - monolithic or functional. I advocate for smaller MPs that contain individual, functional processes. This way, your in-house unsealed MPs become rather analogous to Cireson's MPs of function (Assign Analyst by Group, Send Email, Asset Management) and the same can be said for SCOM and all of it's MPs of discovery/monitoring. But to be really precise within the context of SCSM:

• An MP for provisioning machines (containing the SR/CR, corresponding activities, and Request Offering). This MP could potentially contain processes for decomming a Windows Server, Client, Unix machine, etc. However they are all "like"
• An MP for decomissioning (containing the SR/CR, corresponding activities, and Request Offering). This MP could potentially contain processes for provisioning a Windows Server, Client, Unix machine, etc. However they are all "like"
• An MP for SCOM Incident Templates for alerts triggered from SCOM. This MP would only contain Incident templates and potentially SCO/SMA runbooks for those respective SCOM Incident remediation processes
• etc, etc, etc.

This removes potentially bizarre dependencies between unsealed MPs, allows you to migrate from a dev to prod environment, keeps your customization compact and straight forward, and makes their purpose (i.e. name and description) clear to future SCSM administrators/authors.

I think the best litmus test for anyone following this logic is the following thought experiment - "If I delete one of my unsealed MPs, how many functions/processes would I lose? One? Two? Twenty?"

Jonathan_Boles

Hi @Brian_Wiest, I'd certainly have to go with more MPs with less content. Our organization uses 1 MP per SR type and then split again per Language and again if it's AROs versus standard ROs. This helps us not be concerned with dependencies nearly as much and keeps everything in it's own little place. Also helps out when you have a complex service catalog as well as multiple portal implementations. In our case we constantly have changes on the go, so have more MPs than less helps us to elevate smaller releases without the concern of having other fixes or unintended changes being elevated as well.

Example:
One Service Offering Category - Called Testing
With Two SOs - Submit a Request & Report an Issue 
CompanyName.ServiceCatalog.IT.SR.FR.ARO.Testing
CompanyName.ServiceCatalog.IT.SR.FR.Testing
CompanyName.ServiceCatalog.IT.IR.FR.Testing

So essentially our naming convention and number of categories along with WI type (SR/IR/CR) dictates how many MPs we use (these examples focus solely on Service Catalog but we use a strict naming convention across the board)

Adam_Dzyacky

It's kind of the like the old group policy school of thought - monolithic or functional. I advocate for smaller MPs that contain individual, functional processes. This way, your in-house unsealed MPs become rather analogous to Cireson's MPs of function (Assign Analyst by Group, Send Email, Asset Management) and the same can be said for SCOM and all of it's MPs of discovery/monitoring. But to be really precise within the context of SCSM:

• An MP for provisioning machines (containing the SR/CR, corresponding activities, and Request Offering). This MP could potentially contain processes for decomming a Windows Server, Client, Unix machine, etc. However they are all "like"
• An MP for decomissioning (containing the SR/CR, corresponding activities, and Request Offering). This MP could potentially contain processes for provisioning a Windows Server, Client, Unix machine, etc. However they are all "like"
• An MP for SCOM Incident Templates for alerts triggered from SCOM. This MP would only contain Incident templates and potentially SCO/SMA runbooks for those respective SCOM Incident remediation processes
• etc, etc, etc.

This removes potentially bizarre dependencies between unsealed MPs, allows you to migrate from a dev to prod environment, keeps your customization compact and straight forward, and makes their purpose (i.e. name and description) clear to future SCSM administrators/authors.

I think the best litmus test for anyone following this logic is the following thought experiment - "If I delete one of my unsealed MPs, how many functions/processes would I lose? One? Two? Twenty?"

Jonathan_Boles

Hi @Brian_Wiest, I'd certainly have to go with more MPs with less content. Our organization uses 1 MP per SR type and then split again per Language and again if it's AROs versus standard ROs. This helps us not be concerned with dependencies nearly as much and keeps everything in it's own little place. Also helps out when you have a complex service catalog as well as multiple portal implementations. In our case we constantly have changes on the go, so have more MPs than less helps us to elevate smaller releases without the concern of having other fixes or unintended changes being elevated as well.

Example:
One Service Offering Category - Called Testing
With Two SOs - Submit a Request & Report an Issue 
CompanyName.ServiceCatalog.IT.SR.FR.ARO.Testing
CompanyName.ServiceCatalog.IT.SR.FR.Testing
CompanyName.ServiceCatalog.IT.IR.FR.Testing

So essentially our naming convention and number of categories along with WI type (SR/IR/CR) dictates how many MPs we use (these examples focus solely on Service Catalog but we use a strict naming convention across the board)