Performance-related issues are a concern, as in multiple reports I have seen, some reports were poorly performing. We can focus on implementation of performance so that reports are delivered within seconds. The user interface and self-service experience can be improved through modernization of the UI, addressing self-service limitations, and integrating with mobile. Technical and administrative complexities can also be addressed. Complexities such as system configuration require attention. In the initial setup of Oracle OBIEE, there are multiple things starting from infrastructure provisioning, database schemas, and WebLogic server installations. However, the RPD, the semantic layer, is the steepest hurdle. Security integration, integrating with LDAP or Active Directory, is rarely plug and play and requires deep knowledge of WebLogic. Deep knowledge is necessary when starting with the initial setup of Oracle OBIEE. Other dependencies include Java middleware and client tools. Since Oracle OBIEE deals with huge data, report performance is the biggest concern. The out-of-the-box setup is rarely optimized, so we need to manually check configuration files, such as nqsconfig.ini file settings. For recommendations in Oracle OBIEE, from what I have seen, we work with star schemas in the RPD. I always aim for the star schema in the business model, even if the physical source is normalized. This approach will impact the performance, speed of the data, and accuracy. Oracle OBIEE could improve to allow other schemas as well. Performance is a major area for improvement, and they should work on aggregating the persistence and improve the persistence wizard where we implement aggregations. Caching features have been given, including event polling tables where we can do purging and seeding, but the main focus should be with respect to schema designs.
