Understand Environment and Application Landscapes

This article explains how Application Landscapes, Environment Landscapes, and Tiers can be used to model Applications and Environments composed of multiple parts.

If you are new to Golive, make sure you are familiar with the basic concepts of Application, Environment, and Environment Category first.

For instructions on creating an Environment Landscape, refer to Create Environment Landscapes.

What are Landscapes?

Every Environment in Golive is associated with an Application and an Environment Category.

For example:

ENV-A and ENV-B are regular Environments associated directly with their respective Applications.

ENV-C and ENV-D contain several Environment Tiers and are therefore Environment Landscapes.

Their structure can be represented like this:

ENV-C
├── Application A
├── Application B
└── Application C

ENV-D
├── Application A
└── Application D

Each Environment Tier is itself an Environment that can be managed independently while remaining part of the overall Environment Landscape.

How Application and Environment Landscapes work together

Before an Environment can contain Tiers, its associated Application must define the available Tiers.

An Application with one or more Tiers is called an Application Landscape.

An Environment containing one or more corresponding Environment Tiers is called an Environment Landscape.

The Application Landscape defines which Tiers are available. Each Environment Landscape can then contain all or only some of those Tiers.

For example, the Application Landscape used by ENV-C and ENV-D may define four Application Tiers:

• Application A

• Application B

• Application C

• Application D

ENV-C uses Applications A, B, and C, while ENV-D uses only Applications A and D.

An Environment Landscape cannot contain a Tier that is not defined in its associated Application Landscape.

When the Landscape does not belong to a business application

Sometimes an Environment Landscape represents a shared Environment containing several Applications rather than an Environment belonging to one particular business Application.

In this case, we recommend creating a generic Application named Environment and defining the Applications it may contain as Tiers.

This is the pattern used by ENV-C and ENV-D in the example above.

The generic Environment Application is used to define the Landscape structure, while the actual business Applications are represented by the Environment Tiers.

Terminology

When should you use Tiers?

Use Tiers when parts of an Application or Environment belong together but still need to be managed independently.

Typical use cases include the following.

Environments composed of multiple Applications

A shared Environment may contain several Applications that need to be tracked or deployed independently.

For example:

ENV-C
├── Application A
├── Application B
└── Application C

In this pattern:

• Create an Application Landscape containing the Applications that may be part of these Environments.

• Represent each Application as an Application Tier.

• Create an Environment Landscape for each shared Environment.

• Add only the Environment Tiers that actually belong to each Environment.

• If the Landscape does not naturally belong to a business Application, use the generic Environment Application.

Different Environment Landscapes based on the same Application Landscape do not need to contain the same Tiers.

Their composition can also evolve over time as Environment Tiers are added, unlinked, or relinked.

This allows each Application to be managed independently while the Environment Landscape can still be managed as a whole.

Application modules

Some Applications are composed of modules representing distinct business functions.

Examples include ERP, CRM, and other modular enterprise platforms.

For example:

ERP Production
├── Finance
├── Logistics
└── HR

In this case:

• Model the overall Application as an Application Landscape.

• Represent each module as an Application Tier.

• Use the corresponding Environment Tiers to track module-specific information such as versions, statuses, configurations, data sets, or credentials.

Dedicated microservices

A microservice dedicated to a specific Application can be modeled as a Tier when it needs to be managed independently from the rest of the Application.

Add-ons / Plugins / Third party extensions

Applications such as Jira or Confluence may contain extensions that need to be tracked independently from the core Application.

For example:

Jira Production
├── App A
├── App B
└── App C

The Environment Landscape can store information applying to the complete Jira instance, while each Environment Tier can track information specific to an installed app, such as its version, status, configuration, owner, or licensing information.

Multi-Tenancy

Tiers may also be useful when a shared Application instance contains tenant-specific parts that need to be managed independently.

When should you NOT use Tiers?

Do not use Tiers simply to classify otherwise independent Environments.

Markets, customers, and regions

If the same Application has separate Environments for different markets, customers, countries, or regions, these dimensions should generally not be modeled as Tiers.

Instead:

• Create separate Environments.

• Use Environment Attributes to identify the market, customer, or region.

• Use clear Environment names when this helps users distinguish them.

For example:

Production - Switzerland
Production - France
Production - Germany