Solution Manager Landscape Strategy

[Former Member]

Hi Everyone

Can anyone please point me the document that talks

about Solutiom Manager landscape strategy. Is it recommend to

have Sandbox, Dev/QA/Prod instance of Solutiom Manager or we just need

one instance and connect all other system.

Thank you

[Former Member]

I will add my two cents...

A three SM landscape strategy works pretty good:

#1 - Sandbox Solman - no satellite system connectivity; open access; used for the purposes of testing patches and exploring solman functionality - mostly for basis' purposes.

#2 - 'Development' Solman - only satellite systems that are NOT on the path to production would be connected here - such as a sandbox. This solman system would be used for configuration of solman itself [example, your solman team would configure solman functionality here]. It is also a good practice environment for PM's because it would have a small landscape attached to it [your sandboxes, remember]? Migrations start here for solman functionality...

#3 - 'Production' Solman - ALL path to production satellite systems connected here, except your sandboxes [which were connected to #2 remember?]. This system also serves as a target system for migrations that came from #2 [for solman functionality itself], This is the main solman box that most users will access for project management, blueprinting, config, charm, and so forth.

This type of landscape satisfies ITIL requirements as changes made to solman itself are migrated from #2 to #3; changes are not made directly in the prod box.

Hope this helps,

Jen

[Franz]

We did it like Jennifer, but it is not complete satisfactory, because you cannot close the productive system with transaction SCC4. If you close it, like you do with other productive systems in order to transport all changes from the QAS-Systems, the project functions like creating processes or test plans with test cases is not possible.

Regards,

Franz

[markus_doehr2]

I asked that question also some times ago - but there is no real answer to this.

The problem is, that you can´t connect a backend system to "two" Solution Manager systems, just to one. So if you install a second SolMan you will need a third/fourth backend system to test functionality.

There is no real strategy and if you e. g. use only Maintenance Optimizer SAP told me, that one should "blindly apply" new SPs to the system because the risk of having problems in that area are small. If you use more functionality (service desk or others) it´s always better to have a test system although you won´t be able to really test without a proper configured and set up backend.

So you´re on your own here - maybe create another OSS call and ask

--

Markus

[former_member190969]

The problem is, that you can´t connect a backend

system to "two" Solution Manager systems, just to

one.

This is only true in the case that the destination that joins backend system with Solution Manager system is created in the backend system, which is only true for the older part of the functionality for operations. All implemtation functionality and also newer operations functionality is using destinations in Solution Manager system. Most of the customers I have seen use at least a test system, which is not a bad idea in general. Especially if you use CRM functionality (ChaRM, Support Desk) it is risky to "blindly apply" new SPs.

Regards

Andreas

[markus_doehr2]

Full ack - but maintaining that is a nightmare.

It's becoming worse if you use e. g. change management and do regular system copies on your QA/consolidation and you need to reconnect everything to SolMan again.

Worst scenario is doing system copies of J2EE based products - template installers won't work after copies and you are urged to do everything manually.

We also have a test system and we connect there two "sandboxes" because I can't see how monitoring (EWA, CCMS etc.) should work on regular systems.

--

Markus

[Former Member]

Hi julio,

We have a 2 system strategy generally for Solman as far asi have seen... One for DEV/QTY and the other PROD. That should suffice the requirement..Not much of development happens, so its bstter having them in one box and ideally many a times OSS application would require testing..so in that case we find it helpful...

Hope this input helps.

Best Regards,

Sri

Award points for helpful answers