Without really understanding how your project works and its goals, I would say that your stream topology seems fine. I usually like to consider other aspects of RTC such as builds and work items when planning this structure.

In general, you probably want to have a stream in any instance where you have multiple developers or teams collaborating to produce some result. Usually the result is a build where the sanity of the code is verified through unit testing, compilation and the assembly of the product version.

In small projects you probably only need a single stream for the whole team and a single component (more on that later). Each developer has their own repository workspace for the stream, which they can load (ie. download) the files to their local hard disk to do their work. They can check-in their changes from their hard disk to the repository workspace and organize them into change sets. Checkin-in changes also backs them up on the server. When the changes are ready they can be delivered to the stream for everyone else and also for the next build. One really fun thing about RTC is that you can run "personal" builds with your repository workspace to check that you won't break the real builds when you deliver your change sets. Kind of like a test drive for your changes.

If your small project will be managing multiple releases at once then you will probably need extra streams to collect changes for each release. Also, you'll probably need extra builds to verify, compile and assemble those streams for the releases. New timelines will allow you to assign work items to different releases. Developers have a choice whether they will create extra repository workspaces to match the streams (releases) that they are working on. If there are large differences between them then they may need to create extras (and load/unload as necessary). Otherwise, if the differences are small (e.g. a maintenance release) then they may be able to switch between different streams as the "flow target" of their repository workspace.

For large projects with multiple teams, like in the JKE banking project, you'll notice that there is a hierarchy of streams. There is one for the entire project and individual ones for each team. This allows the team to work on a long running feature without affecting other teams until it is ready. Because the team has their own stream, they are able to have their own builds.

You'll also notice that the JKE banking project uses multiple components. Logically organizing the parts of the product into components allows you to create streams (and repository workspaces) that include some components, but not others. Sometimes it's not necessary for a particular team to have everything in their own repository workspaces, builds, and stream. They can exclude the components that are not needed.

So, how do changes flow from the team's stream to the central stream with all team's changes. Well, there are a few options. First, you can appoint one developer on the team (e.g. the "releng" person) whose job it is to check the team's builds and occasionally use their repository workspace to switch their flow target to the central stream and deliver all of the team's change sets there. Also, the team's builds can be configured to automatically flow changes to the central stream upon any successful build. You can imagine that getting other team's changes from the central stream to your team's stream has the same two options, which you get to choose.

I hope that this helps to explain the kinds of considerations that you can make when planning your SCM stream topology. For further reading there is a series of articles that attempts to show you how to use RTC starting from a small single-person project gradually into a larger project. The context is Mac application development using the command-line interface but the concepts should be the same regardless of the type of product that you are developing.

https://jazz.net/library/article/979
https://jazz.net/library/article/980
https://jazz.net/library/article/981

I hope that this helps,
Chris

That project is a sample that is supposed to give you enough to play with some data. That sample is not a production environment that has bug fix streams or streams for multiple releases.

We have a library with articles for various things. Try https://jazz.net/library/#sort=pubDate&tag=source%20control
to see all articles around SCM. There are several interesting ones.

Also see https://jazz.net/wiki/bin/view/Deployment/RTCProcessFundamentals for a general introduction on all the concepts.

You can introduce new streams for new versions as well as for bug fixes. This is, at least from my perspective, very similar to what you would do with "Branches" in other tools. You use repository workspaces to flow changes between different streams. 

Thank you for sharing the articles. It was really very helpful to improve my  RTC SCM concepts.

Taking your new versions and big fixes streams suggestion as a starting point, I have created a streams strategy diagram for the implementation in our organization. I would appreciate if you could review it and let me know if there are any issues or changes required in the flow.

You can find my created diagram from the link below:

https://drive.google.com/folderview?id=0B5ka4WvpKMx7ZHlBNS1mMm90Ymc&usp=drive_web