A module is a bundle of functionality that can be released separately from other modules. They can be large such as HR, Purchasing or Production. Alternatively, they can be smaller modules with only a few tasks such as Promotions. Modules can also be add-ons to existing modules such as Purchasing analytics.
There are no constraints imposed by the Software Factory when it comes to the size of a module or dependencies between modules.
What defines a module?
One of the major decisions we had to make was on how to limit the application based on a set of selected modules.
We could limit the database objects to those relevant to the selected modules. But this strategy has some caveats:
- Developers would have to tag the module(s) for every single database object.
- Dependencies in the logic layer to objects of modules will cause conflicts.
- Installing or deinstalling modules would require a database upgrade.
- Deinstalling a module comes with potential loss of data.
Instead, we chose to define the module by the roles it supports. Limiting the application to a set of modules will limit the available roles. After all, the roles are elementary pieces of functionality. This fits the definition of a module well - a bundle of functionality.
Further limiting the underlying model based on the selected modules has also been discussed. If no role within the selected modules has access to a certain table, why not omit it from the released model altogether? While elegant, there is no immediate functional benefit in applying this mechanism. This mechanism has been parked but will eventually be developed in a future Thinkwise Platform release.
The deployment flow
Another important decision we had to make was whether we wanted to choose the modules while creating the deployment package or during deployment. For now, we've opted for the former. The modules will be selected when the deployment package is created. The deployment package is then fed into the Thinkwise Deployer, where it can only install roles of the selected modules.
In case no deployment package is created, the modules can also be selected when directly synchronizing to IAM.
The current implementation of module authorization focuses on a scenario where the customer is in full control of IAM and the underlying database platform, either on premise or in the cloud. This means the customer is also in charge of installing or upgrading the product. Having all modules available during installation would be undesirable.
Defining modules
A developer will be able to define modules and determine which roles are part of this module. The Software Factory provides a new menu item where modules and the linked roles can be defined.
A role can be present in multiple modules. If a role is not a part of any module, the role will always be included in a release.
Dealing with logic boundaries of modules
When logic is dependent on the available modules, the easiest way to deal with this is configuration settings in the product containing information about the activated modules. This way, a developer can write logic that uses this information to determine whether or not (for instance) a planning request has to be made in the Planning module once a ticket has been created in the Sales module. Since the database and logic layer is always available in its entirety, this should never cause any form of compilation errors.
Dealing with UI boundaries of modules
When it comes to links between objects of various modules, it does get a bit more complicated.
For instance, when a Logging module causes a log detail to be shown for a number of objects. A detail does not become available unless both parent table and detail table are both granted within the same role, so you will have to grant selection on the parent objects, which technically aren't part of the logging module.
One way to go about this is to turn the logging module into modules with a dependency on one single other module (Logging for Planning, Logging for Sales, Logging for HR). But this can be quite a bit of work and introduces modules that won't necessarily match your licensing structure. When a deployment package is made, you'll have to select your modules more carefully.
It would be a fair to grant selection rights on the parent tables in the roles of the Logging module. In doing so, the Logging module will grant select rights on some tables that aren't necessarily a part of the released modules. But since it only grants selection rights and nothing else, it doesn't grant any access via the GUI to these tables. No functionality is granted to the end users.
This is the same when the presence of a column (often a look-up) is dictated by the combination with other modules. Either you'll have to create modules for every combination, or you will have to grant selection on tables and look-up columns that aren't necessarily a part of the released modules.
Multi-tenancy
When multiple tenants are using the same IAM, the tenants are not assumed to be in control of IAM. In this scenario, module authorization should not be leveraged. After all, we need all roles to be present in IAM.
In the future, we'd like IAM itself to allow for multiple tenants, each administering their own users, user groups and rights to their own applications.
At this point, we'd synchronize the module information to IAM as well. A root administrator will be able to assign the modules each tenant is licensed to use.
Important notes
When roles are no longer available due to the installation of a deployment package not containing said roles, the links between user groups and these roles will be lost. Re-installing the roles in a new deployment package will not restore these links. Keep this in mind when testing various deployment packages.
) with the possibility to sell for a fixed price?