Enterprise resource planners (ERP’s) are known for their complexity and flexibility to fit the needs of possibly any company. Odoo does not deviate from this as they allow their users to fully configure what apps are ready to use. As this subject is very important for Odoo, we decided to discuss variability in detail. More specifically, we will investigate what configurability means for the platform and how it’s achieved. As with previous blog posts, we will be focusing on the core of Odoo and the HR toolkit where needed.

Variability Modeling

To successfully model variability in Odoo we first need to list the features (i.e. apps and addons) available to the users. The on-premise community installation lists the following apps as part of Odoo HR:

• Expenses
• Time Off
• Recruitment
• Employees
• Fleet
• Attendances
• Skills Management
• Lunch
• Employee Contracts

On the other hand, the configurator¹ lists these features:

• Employees
• Recruitment
• Employee Referral
• Leaves
• Expenses
• Planning
• Appraisals
• Fleet
• Approvals
• Lunch

Because of these small differences, coming mostly from the way apps are packaged together and deployed, we will be focussing on the on-premise version, which is more accessible. The most important features are surely Employees, Recruitment and Time Off. Potentially every company can be a user of these apps as they allow them to respectively manage their workers, employ new ones and plan holidays and leaves. Platform administrators can configure which features are installed using the tool Apps. There are cases when a feature will vary depending on what other apps are installed. This happens mostly in the Employees app which is the base for others. For example, the figures below show an employee details view with and without Skills Management app installed. Installing other features will also change the appearance of the webpage.

Configurations

As discussed in our previous post on architecture, apps rely on each other and require some apps to already be installed. This means that from all possible combinations only some are possible. Installing a feature also installs all its dependencies. On the other hand, uninstalling it will give the user information on all other features that will be uninstalled with it. We used this to query the dependencies within the HR module.

First, some apps can be removed without removing any other modules from the system, meaning nothing depends on them. These are Expenses, Lunch, Recruitment, Skills management.

Then apps Fleet, Attendances and Time Off can be removed only with removing some technical modules as a side effect.

Finally, the app Employee Contracts will remove Expenses when uninstalled and the main app in the HR toolkit - Employees will remove: Attendances, Employee Contracts, Skills Management, Recruitment, Time Off, _Expenses _(and some technical modules). This means that if any of the enumerated features is installed, the Employees feature is also present and likewise if Expenses is installed, Employee Contracts is also installed. These relations are depicted in the feature model below. Note that these are the dependencies only within the group of HR products, and some apps have dependencies outside this group, for example, the feature Expenses depends on the app Invoicing from Accounting.

Variability Management

Within this section, we will describe how Odoo manages variability from both the perspective of a stakeholder (e.g. a business) and the developers.

Stakeholders and Variability Management

As has been mentioned before, the Odoo platform has a wide variety of toolkits which consists of many modules (addons). For example, there exists an HR toolkit that has— among many other modules—the Recruitment module which as the name implies helps businesses in their recruitment of potential future employees. Odoo being a general ERP application doesn’t just address the needs of a single stakeholder, but addresses the individual needs of many stakeholders by having a large variety of toolkits. Stakeholders can simply manage their platforms by installing only those specific toolkits which address their needs, of course, this is changeable as stakeholder needs can change over time. Odoo provides extensive documentation² for stakeholders to run different toolkits and to change settings of toolkits if desirable. Developers who intend to update Odoo toolkits are easily able to do using provided instructions in the Odoo documentation.

Easing Variability Management for Developers

Within a toolkit, modules can interact with each other (as mentioned before). As a result of the modules having a good deal of integration points, the need for integration tests arise. Integration tests will be the only way to ensure modules work correctly together. In previous essays, we discussed the technical details of how such integration tests are approached within Odoo.

Besides integration testing, there is another mechanism in-place that is available for the developer to ease variability management during the development lifecycle. Namely, a parent module. Modules within a toolkit often employ a single parent module that contains more general functions that can be used across different more specific modules. For example, the HR toolkit contains an HR module that serves no specific function (it’s not a visible addon for users) besides providing general functions to be available for other modules such as the Employees module in the HR toolkit.

Furthermore, there are tests in place to ensure Odoo works across different platforms (or in this case, web-browsers) with different configurations. These tests are fully automated for existing features in Odoo, developers would need to add or change specific tests depending on which feature was changed or what features were added.

Variability Implementation

As was mentioned, Odoo provides a collection of modules that can be chosen and configured. The main modules are inside the Odoo repository, each within its own folder. This way, they aim to achieve low coupling that allows the developers to change multiple parts without affecting another module.

Implementation and Binding Time

Odoo employs software product lines; a method that aims at “empowering software vendors to tailor software products to the requirements of individual customers”³. In the context of Odoo, new models are created, using the same infrastructure. ERP customization is required to be up to date and generally has an “important impact on strategic alignment and system agility” in companies that employ the system⁴. This makes it important for a company as Odoo to constantly evaluate changing user needs. By analyzing this, Odoo can create new modules that tackle evolving business needs. Users of the system can select a set of modules that are useful for their business and configure and customize their own deployment. In addition, the Odoo suite can also be installed using the source code. This allows users to alter and deploy the suite using a clone-and-own approach.

As for the variability binding time, Odoo provides some freedom. Using a clone-and-own approach or picking the modules via the Odoo website, one could say that the initial binding time is during design-time, since the suite can be altered before running the application. But features can also be installed/uninstalled while the system is up and without any downtime providing a run-time binding.

Moreover, Odoo also provides configuration files and commands⁵ that can alter the workings of the application., server and specific modules. This could be considered as load-time binding.

At last, run-time binding is also available by changing the language for example while the Odoo suite is already online.

Future Extensions

As has been mentioned in the previous essays, Odoo has a structure that handles every module inside a separate folder. This allows for easy addition and extension of modules. However, as some modules could possibly be dependent on others, this can reach some problems caused by changes in one of the two modules. As Odoo uses this structure, the design-time binding is very scalable as long as the modules are low coupled. Low coupling allows for easy updating of different parts of the suite without affecting various other modules. It also makes it easier to add new modules into the platform, which is for example utilized by third parties to create integration apps with their systems⁶.

The load-time binding is also scalable, but could be overwhelming. As a large set of modules are being developed, there is much that can be configured. As Odoo also targets small businesses⁷, many of the configuration options may not be relevant to them.

At last, the run-time binding would only be scalable if small adjustments within the suite are made. Changing the language doesn’t alter the content of a database for example, but changing the workings of a whole module would not be realistic during run-time. This makes the run-time binding well suited for small adjustments, mainly concerned with language or layout.

Conclusion

To summarize, Odoo is a product that supports a lot of variability. From the overall system, consisting of modules, to even a subset of modules such as the HR toolkit. We have looked at variability management and how this eases the development lifecycle. At last, we discussed the implementation of variability and the possible binding times, since Odoo contains a lot of possibilities. At last, we want to emphasize that variability is one of the cornerstones of Odoo. This key attribute is important (see the first blog post), because Odoo targets a wide group of users; ranging from small and medium-sized enterprises (SMEs) to large businesses.