System landscape architecture question

[Former Member]

Hi,

Actually we run our R/3 landscape with 3 systems: dev, test and production. Our test system is periodically refreshed with a production copy. This has one advantage: real data on demand. Also has a big drawback: our project teams loose all the work done in the test system ( current projects, prototypes, etc. ).

We're considering to create a 4th system, oriented to projects, and with the option to provide selected data from production using a tool like SAP TDMS. In this way the landscape that we're considereing is as follows:

dev -> test -> QA -> prod

This seems good for implementation teams, but maintenance teams complaint because we're introducing one new step before to arrive to production.

Is there any similar experience ?? What do you recommend ?? Maybe there is other ways to setup transport routes...

Regards,

Joan B. Altadill

[Former Member]

Hi,

Actually we run our R/3 landscape with 3 systems: dev, test and production. Our test system is periodically refreshed with a production copy. This has one advantage: real data on demand. Also has a big drawback: our project teams loose all the work done in the test system ( current projects, prototypes, etc. ).

We're considering to create a 4th system, oriented to projects, and with the option to provide selected data from production using a tool like SAP TDMS. In this way the landscape that we're considereing is as follows:

dev -> test -> QA -> prod

This seems good for implementation teams, but maintenance teams complaint because we're introducing one new step before to arrive to production.

Is there any similar experience ?? What do you recommend ?? Maybe there is other ways to setup transport routes...

Regards,

Joan B. Altadill

[Former Member]

Joan,

transport routes must be like DEV>QA>PRD.

but if you like to introduce one more layed in between some so you can just create SANDBOX which is just replica of DEV.

in SANDBOX you can do your all project and than no worry when QA is refresh by PRD.because it is a good practice to always refresh QA by PRD in some time because it may take you safer side when ever your PRD crashes.

Amit.

[Former Member]

This message was moderated.

[christine_evans]

When we've had DEV and QA refreshes from Production in the past, BASIS have always re-imported any outstanding transports into the refreshed system so avoiding the loss of any changes.

[ThomasZloch]

Well, you can only save developments and customizing this way, but not application data (like probably the project data the OP is referring to).

Cheers

Thomas

[christine_evans]

I didn't think of that. But thinking about it again.....I don't think losing application data from a QA system would matter much, at least not to us here. The QA system is used for testing changed functionality so you bash in your data and record your results. Once that's been done, it wouldn't matter if the data disappeared.

[ThomasZloch]

Same here. It's good to have actual data in DEV and QA for analysis and testing. But I understand what the OP is referring to, if you build up large test scenarios over time involving application data, one would probably not be amused having to recreate it all.

Greetings

Thomas

[Former Member]

Hi,

- SANDBOX idea seems fine to our purpouses. I will introduce this idea in our design.

- Data is important but project teams are external resources, so data scrambling is also important here, and it's because this that we're considering a 'data moving' tool like SAP TDMS.

- BASIS team won't move requests to sync a copied system with development. Simply there are too much. Note that our SAP Development team has more than 100 people.

Thanks to everybody for this ideas !!

Regards,

Jon