The architecture of the ODI environment is always a hot topic with many different opinions; the reality is that it really depends on the size of the environment, the desired level of security to be applied, etc….
The creation of the repositories is one-off task when first setting up the ODI environment, also some key decisions must be made at this stage of the project, those decisions will impact the way developers will carry their development tasks on a continuous basis, so I suggest some questions are made and discussed amongst the architects, principal developers, and client:
1-Are we going to perform the ODI native version control? If yes, the advantage is, besides of being the best practice of any software life cycle development, it easily keeps the previous code in case you need to restore the previous version of a particular object(variable, interface, package) so if this is the architecture you and your team decided to go with, then you will need one Master repository only, the disadvantage is that a tighter security around the topology will be necessary since it will be the only topology in the whole environment including production, this approach may oblige you as an admin to put more and more restrictive process around topology to control new data sources set up, the pain will fall to the developers especially during development, the reason? The admin or the person who is there way longer than a recently arrived developer may decide to centralize all the actions on him/her and in my “personal” opinion, during development phase we need to try out, test, explore, create new data server, do whatever we need to do, create new physical schema, test it, play with it, etc….
In DEV we need to have a certain degree of freedom to experiment and run tests, but in the centralized type of architecture is not the case, of course, one can argue that “ah we don’t have many data sources so we don’t need to create several data servers very often!” then my question is why should we do version control of the scenarios then in an environment where there aren’t many data sources, if we don’t want to use the native ODI version control we could go for a more isolated approach which means you will have dedicated master and work repositories across DEV, QA and PRD and always keeping the latest version of scenarios(code) in DEV, and whenever a change is required a backup should be taken in case a rollback is necessary.
By the way I guess everyone has their own point of view and opinions and the above is just my point of view as an experienced ODI professional.
2-If we are not going to do ODI versioning then what is the other architecture option?
Well the other option according to Oracle is to have a degree of isolation across different environments (DEV, QA, PRD, hotfix) this is accomplished by having one Master repository per environment with its respective work repositories.The other good thing about that kind of architecture is that depending on the size of the environment especially in those multi-unit organizations you may create multiple work repositories for different data integration projects where different teams, different consulting companies may work on, for example, in those cases where the client/company has multiple vendors on site working in different projects, you can isolate the development by having 1 work repository for every new project, although it may increase the number of repositories to manage.
For simpler environments, we can have multiple projects in one single work rep of development type in “DEV” but security in terms of access is expected, and it is normally ok for a small team .