As Paolo said without knowing more about your organisation and requirements it is difficult to be more specific. When I started that thread I had both a problem and a few ideas on how to solve it, the discussion on the thread shaped and is still shaping the solution to the problem.
They factors to consider are:
1) the size of your organisation, in terms of the headcount and revenue but also in terms of the size of your Information Systems landscape. The bigger the Information System landscape the lower is the probability of being able to properly document it (before it changes).
2) the (real) level of competency of the users (specially authors), both as architects/business analyst and Sparx users, and how many of them you have. Please note that there is a natural human tendency to believe that we know more than we really know and this manifests when we need to do what we know.
3) Sparx limitations and complexity. Cloning projects, creating baselines, using source control and so on are all possible in Sparx but they all require a good working understanding of the concepts involved and Sparx. They also require maintenance.
4) Governance, I don’t think you can have a fully self-governing architectural repository. Some modern methodologies do not emphasise governance.
To sum up, for a large organisation I would not recommend partitioning the repository in terms of the As Is and the To Be. Instead I would model-the-model, this involves breaking the model down into domains, both stand alone and crossing, and creating a self-containing repository branch - i.e., folder/package for each domain. This leaves your with the problem of controlling duplication, which you can achieve by having your core elements on stand alone domain packages and specialising them on crossing domains.
One last lesson learnt, thanks to Geert, I would put my documentation in a separate branch from my actual models. Report packages and master documents are of great help for this.
More details are available on the thread link provided by Geert.
