Stuck in the MUD: How to Approach Multi User Development in OBIEE
It is easy to get stuck in the MUD (multi user development) with OBIEE. I wish I had a better name for it (such as MDE for multi development environment or MODE for multi-user OBIEE development environment), but I don’t. It’s MUD. The good news is: it doesn’t have be messy. With a strategy in place, you can navigate the murky waters with ease.
For the non-OBIEE audience, I offer this short intro. OBIEE’s code is contained within a binary file, making traditional (text-based) development and version control impossible. Several new features were introduced with 11g, such as XML export and version-control support. However, they do not provide the same functionality because of the way objects are storied within RPD. So, once you have more than one person working on the RPD — whether an architect, developer, or business analyst — you are in a MUD situation.
There are several ways that I have seen companies deal with OBIEE’s MUD. The most common one is running RPD on a development server and having developers make RPD changes in online mode. I cannot recommend this method for several reasons — the two most important being instability and concurrency. While simple changes do not usually pose a threat, I have seen situations where RPD was locked/corrupted over certain development activities. This includes editing dimensional hierarchies and changing complex joins. Another disadvantage of this approach is that only one person can work on a subject area at a time because a checkout during editing prevents other users from working on checked out objects. Finally, there is no way to track who did what in the RPD.
The second method of RPD development by multiple users includes juggling a single RPD file between developers. Frequently, an object is placed on a table of the person working the RPD. Other developers then work on web catalog or documentation. This wastes time. Team members must be in the same physical location, especially because projects require coordinated management and deadlines.
The third method involves teams working on separate RPDs and then relying on merging those separate projects into coherent deployment RPD. The benefit to this is that teams do not have to rely on each other. It also eliminates the disadvantages of the previous two methods. Done right, it can be an extremely effective technique. However, there is still significant management overhead and coordination required in order to avoid conflicts.
Fortunately, OBIEE has a built-n MUD functionality that solves many of the issues (i.e., independent projects, avoiding conflicts between different semantic layers, easier project merging, basic version control/history). However, it still requires planning — not just an ON button. By establishing the MUD process and procedures as well as putting an effort into training your RPD developers, you create a strategy that is comfortable and effective.
Please let us know if you would like us to help you with your OBIEE MUD strategy.