What is a multi-tenancy:
Lets take a few use cases:
A large organization has multiple units, each maintaining a separate business application and underlying transactional database. Each one has a different user base, and security considerations when it comes to data access. Data can be collected in individual data marts and a BI solution can be built on top of these data marts. This way the different departments have independent control on the development, release and usage of these BI solutions. This is not an ideal solution, and eventually these data marts should be converged into a central data warehouse, but until than...
A product offering decides to offer a self service BI add-on. The product runs on a distributed database mode where each client has its own physical database/schema running off a common data model. This can be implemented two ways, one by bringing all the data into a central Data Warehouse, or by creating parallel data marts for each clients. In the second scenario, the BI implementation can have a common RPD and Presentation catalog, connecting to the individual data marts, with provision for custom reports in the catalog.
BI on the cloud. Many states are centralizing their IT functions into a 'technology' agency. The rule of thumb is that if any two or more agencies use a platform, that platform should be handed over to this central agency for hosting, management etc to conserve costs. In this scenario, the agency can host various BI servers and allow the agencies to buy time, space and bandwidth in these servers.
A large financial institution manages retirement and benefits plans for various companies. The data warehouse is central, but the BI dashboards are customized for each client. The security implementation is also different and there are various level of support and custom/self-service solutions that the clients can buy into. The clients can negotiate a different upgrade timeline for their dashboards which may result in different micro release cycles effecting development/testing and other SDLC lifecycle.
Each of these use cases presents a Multi-tenant implementation scenario. The site(s) needs to be envisioned, designed, developed, deployed and managed in sync with each other.
Oracle's OBIEE documentation defines 'Multitenancy' as:
Multitenancy refers to a principle in software architecture where a single installation of the software runs on one server or clustered servers, serving multiple client organizations. With a multitenant architecture, each client organization operates independently of other organizations that share the same infrastructure. Multitenancy offers the ability to host multiple companies (even competitors) in one deployment without them knowing of each other..
Issues: Code Management
One of the major issues comes wrt code management. To run a successful multi-tenant implementation, the central administration should be able to cope up with multiple release schedules, dependencies during the deployments and coordinating rollbacks and out of schedule/emergency deployment requests.
One installation/implementation of an OBIEE server can only support one RPD - the model against which the users can create reports and dashboards.
RPD is a piece of monolithic code, which is deployed as a single item. Internally for the ease of multi user development, the code can be structured as project. A project can be worked upon as a smaller rpd to shorten and simplify development effort and unit testing.
The RPD is a three layer model consisting of a physical, business and presentation layer. A project consists of Presentation layer subset areas and their associated Business and physical layer. A project can be defined in a way that it serves a particular 'Tenant' in an implementation, thus isolating the deployable unit of code.
Ideally, multiple deployments will have common Dimension tables and some fact tables, and that can throw a spanner in this while design, but then that may also gravitate towards consolidating things into a single Data Warehouse. That is a topic for another blog.
That said, experience tells that RPD is still a monolithic piece of code when it comes to deployment, and on the other hand the presentation catalog is very fragmented. The deployable artifacts are
- Folders
- Reports
- Prompts
- Filters
- Dashboards
- Security
- ...
With one deployable file for each of these and their corresponding security metadata. To add to the mix, the Presentation catalog has an organic growth pattern. Users can create new artifacts, and modify existing ones in production.
it is a challenge to simultaneously manage a deployment with two code units, one monolithic and the other fragmented.
Next I will discuss the Presentation Catalog implementaion- OBIEE - Multi-Tenancy - Presentation Catalog
Sachin
Architect - Oracle Engineered Systems
Exalytics/Exalogic/Exadata
BuzzClan LLC
BuzzClan is a business consulting company collaborating to provide Oracle software advisory services & implementation services.
BuzzClan LLC is committed to providing substantive business value on each and every client engagement. We do this through a combination of industry-specific business expertise, technical skills, proven project management methods and our “onsite - off site - offshore” delivery model. We strive to work in partnership with our customers to build high-performance teams and create business solutions that will last.
