Skip to main content

Managing Target Architecture Preferences in Groups

Target Architecture Preferences are often shared across multiple applications to allow for a common streamlined cloud strategy. In Txture, several different asset types can contain Target Architecture Preferences that are shared in different ways:

  • An Application can contain its own (local) Target Architecture Preferences. They are not shared with any other Application.
  • An Business Applications can contain Target Architecture Preferences. They will be applied to all Applications that belong to this template.
  • A Cloud Preference Group can also contain Target Architecture Preferences. They will be applied to all Applications and Business Applications that belong to the group.
  • There is a set of Global Target Architecture Preferences. These global preferences are usually strategic choices in nature and affect all applications in the Txture repository.

Preference Merging & Override Order​

When there are multiple sources for Target Architecture Preferences available for any given Application, Txture will attempt to merge the preferences together. Two sets of Target Architecture Preferences, A and B are merged together by combining their individual settings as follows:

  • If A does not specify any preferences for a given setting and B does specify it, then the settings specified in B are used. This works in both directions.

Example: The Global Preferences (B) specify that the Landing Zone should be Public Cloud. The local Preferences at the application (A) do not specify any Landing Zone at all, so the Public preference is used, even though local preferences would otherwise take precedence over global ones.

  • If A and B both specify preferences for a given setting and A overrides B, then the rule defined in A will be used.

Example: The global preferences (B) specify that the Technical Similarity should be Very Important. The local preferences at the application (A) specify that the Technical Similarity is Desired. Since the local preferences override the global ones, Desired is used.

The override order for an Application works as follows (later in the order means higher priority):

  • Global Target Architecture Preferences
  • Get overridden by: Preferences of the Business Application Cloud Preference Group
  • Get overridden by: Preferences of the Business Application
  • Get overridden by: Preferences of the Cloud Preference Group
  • Get overridden by: Preferences of the Application (i.e. local preferences)

The override order can be explained in the following example:

Let's assume that each of the assets presented in the visualization above has a set of Target Architecture Preferences attached to it.

For Application 1 (Production), the following override order is used (later in the order means higher priority):

  1. Global preferences
  2. Preferences from Cloud Preference Group 1
  3. Preferences from Business Application 1
  4. Preferences from Application 1 (local preferences)

For Application 1 (Testing), the following override order is used (later in the order means higher priority):

  1. Global preferences
  2. Preferences from Cloud Preference Group 1
  3. Preferences from Business Application 1
  4. Preferences from Cloud Preference Group 2