Skip to main content
OutSystems

The 5 rules for correct application composition

The need to split applications, after the reuse needs are known, is something you always need to address. However, splitting one application into smaller ones upfront is not always obvious.

These 5 rules guide application composition in order to:

  • Minimize dependencies
  • Simplify deployments
  • Promote life cycle independence

The first two rules are the result of correctly using the 4 Layer Canvas methodology. The remaining three take into account other strategic considerations, driving the decision for creating smaller applications upfront.

Rule #1 - Correctly layer your modules

Follow the 4 Layer Canvas principles. If the module architecture contains violations, it may be impossible to get to a correct and manageable application architecture.

Rule #2 - Correctly layer your applications

Follow the 4 Layer Canvas principles when applied to applications instead of modules.

Rule #3 - Don’t mix different change paces

To manage less applications, it is common to group together modules that support several applications. For instance, application Core services in the following scenario.

This is not a bad policy, as long as all the modules are stable. In this example, the unstable module changes regularly, creating unnecessary impacts on App and App that do not consume it.

To minimize the impacts of constantly changing unstable modules, the solution is to isolate those modules into a different application. This can be a temporary situation, placing unstable modules in quarantine until they become stable and can return to the original application.

This rule applies only to OutSystems Platform up to version 9.0. From version 9.0 onwards, the deployment process models dependencies among modules and automatically deploys only the ones that have changed.

Rule #4 - Don’t mix different owners

With different teams developing different projects simultaneously, it is common to get requirements from both projects that affect common services. To avoid bottlenecks, one common temptation is to allow both teams to change the common resources.

Having more than one owner for an application results in complex deployment management, as accountability for what has been changed becomes unclear.

 

Promoting ownership is key. If it is not possible to concentrate the ownership of one application, consider splitting it in such a way that ownership is clearly defined.

Rule #5 - Don’t mix different sponsors

If a project affects several sponsors, it is important to isolate each LOB (Line Of Business) in a different application. Different sponsors have different budgets, requirements and change paces.

The following example above shows a common Portal to grant web access to all sort of insurance simulators, from different LOBs: Auto, Life and Property.  

Splitting the application upfront, by LOB, enables the independent evolution of each one. The isolation of all the common services clearly sets the border between what must be carefully planned due to the expected transversal impact, and what can be flexibly changed inside each LOB.

More information

To learn more about how to design your application architecture check the Designing the architecture of your OutSystems applications guide.

You can also check for further recommendations on how you should compose your application landscape.

  • Was this article helpful?