ExtraView is architected to allow you to create within a single database an unlimited number of systems (i.e. “Areas”) and subsystems (i.e. “Projects”). Each Area and Project can have its own workflows, layouts, sub-layouts, business rules, notification rules, administrators, security, privacy, etc.  Hence, different parts of your organization, such as Engineering, Marketing, and Human Resources can each create and maintain within one database their own Areas and Projects.  For example, you might create an Area called “Human Resources” that contains four Projects (e.g. “Training”, “Recruiting”, “New Employees”, “Staff Evaluations”, etc.).  You could also create a second Area called “Engineering” that contains three Projects (e.g. “Defects”, “Requirements”, “Test Cases”).  Using a variety of ExtraView’s configurable security settings, each Area and Project can be granularly locked down as required, even to the point where users cannot tell that they are sharing the same database with users from other Areas and Projects.

Given that, a common question I’m asked by ExtraView administrators who are looking to roll out their second ExtraView system is whether they should put that new system in a new ExtraView instance or create it within the existing instance.  An ExtraView instance that contains multiple systems is sometimes referred to as a multi-tenant instance.   There are pros and cons to multi-tenant instances. The pros are: consolidated reporting, shared licenses, and one database to maintain.  The cons include:  additional coordination, additional complexity, and little or no improvement in hardware utilization.

Pros of a Multi-tenant Instance

Consolidated Reporting – ExtraView has robust native reporting capabilities. Any user can easily create and share any number of reports and dashboards in a variety of formats and filters.  When multiple groups reside in the same ExtraView instance you can create reports that consolidate data across all groups within that instance.  Hence, in one site you can have a consolidated dashboard that allows management to view metrics and trends for all groups within the ExtraView instance. If those groups were in separate ExtraView instances, management would have to log into each site in order to see the same data, and the trends would not always be obvious.  (Note that the ability to render consolidated reports does not mean all users will automatically see all data within the ExtraView instance. You can use a variety of security and privacy settings to hide as much of your data as desired.)

Shared Licenses – ExtraView supports named and concurrent user licenses. Named user licenses are assigned to individual users. Concurrent licenses can be shared across multiple users within the same ExtraView instance. When a user who is assigned to concurrent licenses logs into the system, they “check out” one of the available concurrent licenses from the “bank” of available concurrent licenses. If all the concurrent licenses have been checked out, then that user cannot log in.

Concurrent licenses cost 4.2 times more than named user licenses. Hence, in general it is most cost-effective to assign named user licenses only to users who will spend most of their day working in ExtraView and assign concurrent user licenses to everyone else.

Given that, there is a financial benefit to putting multiple groups into the same ExtraView instance because a larger group of users can more effectively share a pool of concurrent licenses. This is particularly true when users are dispersed across distant time zones. Similarly, there’s a financial benefit to a multi-tenant ExtraView instance if particular users need access to the same systems within that instance. This benefit is magnified when the user requires a named user license.

That said, there are various times when there’s negligible potential financial benefit to sharing licenses within a single instance. For example, there’s no benefit if most of your users require named user licenses and do not need access to both systems. Likewise, the financial benefit is diminished if most of your concurrent users are located within the same time zone and/or will simultaneously access the system.  In addition, sharing licenses across multiple groups can present administrative challenges.  Oftentimes these administrative challenges outweigh the potential benefit of sharing licenses.  For example, as the group sharing the licenses gets larger, it requires more effort to identify which group is actually using the licenses more.  This is often problematic because licenses are funded from different group budgets.

Database Maintenance – There are various typical tasks associated with setting up and maintaining an ExtraView instance. Set-up generally includes installing the software (i.e. ExtraView, application server, web server, and database software); configuring that software; establishing URLs; configuring LDAP/AD; importing your schema; setting up monitoring and back-ups; etc. Maintenance tasks generally include making sure your monitoring and back-ups continue to work properly. Most of these tasks are not very time-consuming; however, there is marginal benefit to doing them once for one ExtraView instance instead of multiple times for separate instances.

That said, most set-up tasks need only be done once, even if you maintain multiple separate ExtraView instances. For example, you need only install once the database software, the application server and the web server software. (Note:  ExtraView is designed to allow you to run multiple instances within one application server, and run multiple application servers on same server hardware.)

Likewise, once you configure backups, monitoring, and LDAP/AD for your first ExtraView instance, it’s very easy to set these up for subsequent ExtraView instances. In our experience, which includes managing thousands of hosted ExtraView instances since 1999, there’s little measurable incremental effort to maintaining multiple ExtraView instances vs. a multi-tenant instance(s).

Cons of a Multi-tenant Instance

Coordination Required – If two or more groups reside within the same ExtraView instance, they will need to coordinate various tasks, such as upgrades and significant new development. Upgrades and significant new development involve some risk that existing functionality can “break”, and thus we recommend you thoroughly test your ExtraView system when performing these events.  Sometimes it can be very difficult to coordinate these events, such as when each group is on different product release schedules or calendar events. A group in the latter stages of a product release or in the middle of their quarter end close is not likely to want to undergo an upgrade.

You will likewise need to coordinate on the set up of certain global objects in a multi-tenant ExtraView instance. For example, you will need to coordinate the list values that appear in key global list fields, such as Status or Product. If you don’t coordinate these, you will likely end up with redundant list values (e.g. multiple Status fields that mean the same thing, such as “New” and “Submitted”) or numerous redundant list fields (e.g. two or three fields called “Product”). Once that happens you lose much of the benefit of consolidated reporting described above.

Additional Complexity – A multi-tenant ExtraView instance can be more complex to set up and maintain. The primary reason for this is that when setting up your site you will continually have the opportunity to configure functionality at either a global or group level. That additional choice provides complexity. For example, does it make sense to create two separate roles, such as “Engineer” and “Developer”, or is it better to have one role and use other configuration techniques to control what that role can do in each Area and Project? You likely wouldn’t need to make that configuration decision where each group maintains their own ExtraView instance.  Likewise, if in the future you wish to modify the security settings associated with each Role, it is more complicated in a multi-tenant ExtraView instance.

Although ExtraView’s architecture provides comprehensive security, setting up and maintaining that security is the result of turning off and on many behavior settings, security permissions, and other configurations.  This can become more complicated with each group you add to the instance.  Furthermore, eventually you increase the risks that human error could result in a change that unintentionally exposes one group’s data to another group. Hence, maintaining separate instances is generally more secure.

Finally, other tasks can also become more complicated in a multi-tenant instance.  For example, you will inevitably need to tear down and archive group systems that are no longer used.  That is much easier to accomplish when the data is maintained in a separate instance.  You will also need to periodically migrate some systems. For example, many of our customers start off hosted on our servers but eventually migrate to their own in-house servers.  That migration is much easier because we maintain their data in separate instances.

No Increase in Hardware Utilization – A common argument for multi-tenancy is that you gain cost savings through better utilization of the hardware. However, for the past twelve years we have hosted many thousands of customer sites and have seen little difference in hardware utilization between hosting multi-tenant vs. separate instances. In fact to the contrary, we have found that a multi-tenant instance is generally more complicated and requires more powerful hardware.  More specifically, in a shared instance you need to size hardware to accommodate the most complex processes/groups.  This can often be more expensive than just breaking those processes/groups out into separate instances.  For example, we find that we can generally put up about seven Tomcat application servers on a modest server, and each Tomcat can hold about 15 ExtraView instances. Hence, one modest application server can host up to 105 unique ExtraView instances. When those customer sites are much more complicated, we find that performance improves if we separate them from the other ExtraView instances and even allocate them multiple Tomcats.

Ultimately, you will need to weigh the pros and cons of a multi-tenancy vs. separate multiple ExtraView instances strategy.  Fortunately, the ExtraView architecture supports a broad variety of deployment strategies.