Multiple products in a Project Area
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
5 answers
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Comments
![](http://jazz.net/_images/myphoto/e93281badf6faa95fbc0fb9ccc941dfd.jpg)
In RQM you can do it by using the "team area" feature.
I think in RTC you can do it as well.
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
I am asking for source control management in RTC.
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Daniel,
I am referring to project areas managed by RTC where components are source files.
Basically, we need to finalize our strategy of how should we manage our different solutions (i.e. our products) in RTC.
Do we need to create separate project area for every product OR we should go with only one Project Area per product? (if this is the approach then how it is possible in on project area)
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Comments
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
So, do I have to the make my project area hierarchy like below:
MyProjectArea ---> Team Area (Product A) ---> SubTeamArea1 (Product A) & SubTeamArea2 (Product A)
MyProjectArea ---> Team Area (Product B) ---> SubTeamArea1 (Product B) & SubTeamArea2 (Product A)
MyProjectArea ---> Team Area (Product C) ---> SubTeamArea1 (Product C) & SubTeamArea2 (Product C)
and the other product continues ....
Can I manage all the products in one project area ? (like above or there is any other practice)
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Multiple component, is to divide your huge set of files into coherent and logical subsets, more identifiable and manageable.
Note: in RTC, you can reuse a component (defined in one project area) in another project area.
You can put it all in one component and leave the directory structure.Note: One of the reasons for different access control.
Streams are largely about allowing for parallel development, so is largely independent of your component layout.
Please refer the below blog it might help you.
https://www.ibm.com/developerworks/community/blogs/32f9d388-7f35-4598-a08a-7cd6c0bd3841/entry/how_to_decide_on_rtc_components_during_a_migration17?lang=en
Regards,
Arun.
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Comments
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Thanks Geoffrey,
I understand two points from your answer, components are independent of Project Area and we should not create separate team areas for each product.
However, still I could not find the answer I am looking for. Let me paste my primary question of this thread again:
Q. If I want to use multiple products in one Project area then how can we manage it? would each product will be managed in each component or there is any other practice ?
![](http://jazz.net/_images/myphoto/a36d1dcfd3e1e1e00aeb18c860d1443d.jpg)
As Ralph indicates a component is a logically-related set of files. If all of your products are completely independent (share no common source code), then each product will have its own component (or set of components). But if two products share some common source code, then that common source code would be placed in one or more separate components, and those components would be used by both products.
![](http://jazz.net/_images/myphoto/d6f498a1f41dfdbb5dd1859d222aa4cd.jpg)
Q. If I want to use multiple products in one Project area then how can we manage it? would each product will be managed in each component or there is any other practice ?
Assuming you talk about RTC, which I have to assume due to the lack of tagging, how should one answer this question, if you don't provide any details at all? What is a product? What do you want to do with it?
Making a host of assumptions, my answer would be.......
SCM: Components usually map to some partition to the code i.e. architecture such as common, repository, ui, build
So unless your products are all isolated and don't share any code between them, components are not the level of organization you want.
If your products share code, you can organize a products code in a stream. You would have different streams for different products and also streams for different versions of them.
Change management - work items and planning
If you want to be able to plan for and report work items against products, you need to be able to distinguish them somehow. In RTC you can have multiple project areas as one option. Another option is to create categories in a RTC project area that reflect the products somehow. e.g. Product1, Product2, Product2.
Categories can be mapped to team areas, so you can manage different teams working on their products. e.g.
Project Area/Product 1 Team
Project Area/Product 2 Team
Project Area/Product 3 Team
Planning involves also development timelines. Each area (project or team) can only be associated with one timeline. If the teams have different rhythms, you need different timelines for each team.
Finally, when to use project areas vs team areas: This really depends on
1. Complexity. If you have very complex products you will likely end up with multiple project areas. If they are simpler Team areas may do.
2. Flexibility and administrative overhead. In a project area, all teams have to follow pretty much the same process. If you have completely different processes and want more flexibility, you would need more project areas. Project areas add a lot more possible administrative cost compared to team areas, but have more process flexibility.
3. Organization: In some organization it is not possible to map people to products, the people are pooled and work in their area for the projects (department). In this case the team areas often reflect that structure, sometimes even broken up in project areas. In cases like that, there is often one or more additional project areas where the products are planned and the work tracked down to the team/project ares where the developers are located.
This is not always the case and you can also have users associated to multiple project and team areas and assign their availability there, which also has tradeoffs.
Please see: https://jazz.net/wiki/bin/view/Deployment/SetupProjects for a bit more information. Unfortunately there is no one size fits all approach, but fortunately you can start with one approach and evolve from there.