cancel
Showing results for 
Search instead for 
Did you mean: 

Does CHaRM support a dual track system landscape phased project approach?

Former Member
0 Kudos

Hi All.

I'm in the process of rolling out NW 2004s SR2 (ECC 6.00, PI/XI 7.00, BI 7.00 & Solution Manager 4.00) here driven centrally from a SAP Solution Manager project connected to the local DEV img's and I'm considering using CHaRM.

As this is a "phased roll-out" (by Business Division) we are implementing a dual track system landscape (SAP Standard) with dual Dev & QA systems in the ECC 6.00 landscape. The deployment plan is as follows:

Release 1 Implementation

ED1 -> EQ1 -> EP1

Release 2 Implementation (Release 2 into Support)

ED1 -> EQ1 -> EP1 (Support track Release 1)

ED2 -> EQ2 -> EP1 (Release track after cut over to production)

Release 3 Implentation (Release 1 & 2 into Support)

ED2 -> EQ2 -> EP1 (Support track Release 1 + Release 2)

ED1 -> EQ1 -> EP1 (Release track after cut over to production)

Release 3 etc. up to Release X with the Dev system alternating between Support and Release tracks.

It's a little bit more complicated than that as we have production approved transports going to Migration and Training but I assuming that the TMS delivery group will handle that.

I am assuming that you would have an "implementation cycle" project and a "maintenance cycle" in existance with CHaRM at the same time with the systems being moved within project landscapes within SMSY.

The big question for me is that we intend to "feed back" production approved transports from the Support (maintenance project) into the Development system of the next release track (implementation) to handle potential clashes between objects changed between releases.

The frequency and scope of the clashes is assumed to pretty low as we are 90 - 95% SAP standard, to a near enough common template between Business Divisions / Releases with the bulk of the project scope post initial go-live being data migration work.

On previous projects using Enhanced CTS and TMS with QA approvals and Virtual systems, I've checked for these "clashes" using a variety of bespoke reports (Accenture) and manually on transport error but does anyone know how CHaRM would handle this or do this for me automatically?

the questions.....

1) Does the "cross client / system" lock have anything to do with this?

2) Has anyone else out there done this before?

3) Is CHaRM stable and mature enough to support this?

4) How would the link between the two landscapes / project work?

5) What's the integration with CTS+ for non ABAP (PI/XI) transports / objects like with CHaRM?

6) Does it work like a CHaRM?

Sorry for the chapter and verse (long post) but I wanted to state the position clearly. SAP AGS are hopefully lining up a day's consultancy on this with a CHaRM expert but that's a few weeks off and some blueprint deliverables are looming.

Any assistance, advice, guidance or real life experiences with this would be truly appreciated...

Best regards

John Watson

SAP Basis Consultant.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi David....

Thanks for the response, good concise advice of which i will duly take.

Nice to have a the decision ratified.

All the best and thanks again.

John W

Former Member
0 Kudos

John,

Your planning is quite sound and should be on-par for ChaRM with a few corrections to your assumptions. One is that when you have a dual-landscape as such, you really cannot automate the support transports into the next release - this should be done manually for a number of reasons but a good pratice to get in so when you apply support packs or upgrade, you are already used to it. One other good reason for doing this is that not every change is necessary in the next release - additionally some changes can cause problems (such as old notes being applied to a system that is already ahead in support packs due to the next release - also developer code can get overwritten if the change is in a program that has changes applied due to the next release). Killed that to death but it is an issue that you should keep from getting in the middle of and manually helps ChaRM to work properly as you create the new change in the support landscape manually so it will cancel out when you goto production if it is a necessary change. One good point to use to keep things sane is that you don't send a transport to PRD unless it has been applied or addressed in the next release.

This answer also keeps you from running into issues with Urgent Corrections feeding back to the other landscape because they are two distinct cycles. If you lay it out on paper - it makes sense and keeps things simple, which is what you want to do - keep it simple as much as possbile.

Additionally there are other ways to do this which are completly different than how you are expecting to do it that work even better with ChaRM, but require a lot of developer control. Just not enough time and space in a question/answer thread to talk about all of these possibilities.