Streams and Components in Source Control Compared to Config Enabled PAs

Thank you both, I'm still not quite getting my head around it... perhaps an example might help using the GCM and RM structure... assume that the sys and sub-sys are from the same RM PA and EWM/RTC PA 

You have a couple of choices.  You could create explicit EWM streams in each of your EWM sub-system components, and contribute those to the appropriate GC sub-system configurations (and each EWM sub-system stream then sit alongside the RM stream).   But to effectively populate EWM workspaces, you would want to flow all of those sub-system streams with an EWM system level stream.   If you don't want to pay the overhead of creating those explicit EWM sub-system streams and keeping them in synch with the EWM system stream, you could just contribute the EWM system stream to the appropriate GC system configuration, and give up on having EWM sub-system streams sitting alongside the RM sub-system streams in the GC hierarchy.   This is simpler ,but you lose the ability to create a baseline of that GC sub-system stream and have it capture the appropriate baseline from both RM and EWM.

Thanks. Within our sub-system teams we operate relatively independently and there may be many months between sub-system releases/milestones and equivalent system releases/milestones.  I think keeping them separate is probably better for us to be able to maintain separate baselines and releases throughout the project. 

Are you suggesting separate PAs for each GC subsystem? 

The main reason to create a separate GC PA  is if you have different read access requirements for different global components.   Some customers who have a huge number of global components or streams create multiple GC PAs, but with appropriate naming conventions, this is usually not necessary because of the tagging and name-wildcard filtering provided by the GC application.