Hi,
You've hit one of the classic EA inconsistencies here: "model". In the documentation, the term "model" sometimes refers to a project, sometimes to a root node and sometimes to a package.
When discussing these things, I actually prefer yet another definition which is that a model is "a collection of packages, diagrams, and elements, all contained in a single package". In other words a "model" is a unit of modelling content, or a package-and-its-contents, which can be moved around in a project (and also exported and imported between projects), while a "package" is only just a UML package and not a package-and-its-contents.
In addition, a "project" is an EA workspace and a "repository" is a storage for one project (either a database or a file). These are pretty uncontroversial.
This terminology allows you to separate concerns when working with EA.
Repository issues are essentially pure IT. What DBMS or fileshare are you using, who is permitted access, how often do you take backups, that stuff.
Project issues are questions of how you configure the workspace, structure the content, what methodology you allow / mandate, how you distribute content (WebEA access, generated documents, generated HTML, reusable assets...), how you track changes, etc.
In an enterprise environment, you want to assign project administratorship to specific individuals who need special training but don't need to be black belt modellers.
Model issues are content issues. These depend entirely on what you're actually modelling so it's hard to be specific. Is this use case correctly documented, that kind of thing. This is modeller territory.
Finally, method issues. You will probably need to develop at least some tool adaptations of your own to reflect your own methodology. This can include document generation templates (most likely; the built-in ones are generally only useful for demos), UML profiles, customized searches and scripts to perform various tasks, data import/export functions, etc etc.
In an enterprise environment you probably don't want modellers to roll their own adaptations, but rather maintain a set of centrally managed "MDG Technologies".
Other than "repository" and "project" these are not universally accepted terms or structures, but it's what I like to use when advising enterprise clients.
/Uffe
