Environment and Application Landscapes

This article explains what Application Landscapes and Environment Landscapes are, how to use them effectively, and when not to use them. For instructions on how to create an Environment Landscape, refer to the Creating Environment Landscapes article.

Info

If you want to convert an existing Environment into an Environment Landscape, refer to the Adding Tiers to an Environment article.

What are Landscapes?

A Landscape represents a logical breakdown of an Application or Environment into distinct components or modules, referred to as Tiers.

• When an Application contains one or more Tiers, it's called an Application Landscape.

• When an Environment is associated with an Application Landscape, it's called an Environment Landscape.

Tiers are used to model the structure of Applications and Environments where components need to be managed, tracked, or deployed separately.

Adding Tiers to an Environment

To add Tiers to an Environment, its Application must already include tiers. This means the Application is an Application Landscape. In this case, the Environment becomes an Environment Landscape.

Only Tiers that are part of the Application Landscape can be added to the corresponding Environment Landscape. It's possible to include fewer Tiers, but not to add Tiers that are not defined in the Application Landscape.

Naming Convention

When Should You use Tiers?

Use Tiers when you need to manage or track components of Applications or Environments independently. Typical contexts include:

Environment Landscapes

An Environment Landscape includes multiple Applications deployed together in the same Environment. For example, an eCommerce Staging Environment might include:

• Hybris

• Pickup Point

• Payment

While each Application can be deployed independently, you may want to allow users to reserve the entire Environment Landscape.

How It’s Modeled

• An Application Landscape (e.g., eCommerce) is typically structured with three Tiers: Hybris, Pickup Point, and Payment.

• One Environment Landscape exists per Environment category, such as eCommerce Test, eCommerce Staging, and eCommerce Production.

• Each Environment Landscape includes the same three tiers, for example:

  • eCommerce Test: Hybris

  • eCommerce Test: Pickup Point

  • eCommerce Test: Payment

This structure allows users reserve individual Applications (Tiers) or the full Environment Landscape, while tracking configuration attributes at both levels.

Application Modules

Many ERP, CRM, and industry-specific platforms are modular, supporting distinct business functions.

How It’s Modeled:

• An Environment Landscape for the full Application.

• Each module is represented as a Tier to capture specific setups, data sets, credentials, statuses, and other relevant attributes.

Examples: SAP, Oracle, Microsoft Dynamics, Salesforce, Temenos, Infor.

Dedicated Microservices

Dedicated Microservices refer to services that are specifically designed and developed to perform a specific function within an Application. Unlike general-purpose or shared microservices, which can be used in multiple Applications, Dedicated Microservices are tightly coupled to a particular Application and cannot be easily reused elsewhere.

How It’s Modeled:

• Each microservice should be modeled as a Tier within an Environment Landscape.

Important

For shared microservices, prefer modeling them as Environments (without Tiers) and link them via Dependencies. For details, refer to the Environment Dependencies documentation.

Add-ons / Plugins / Third party extensions

In an Add-on based system, the core system provides a base set of features and functionalities, and users can add additional features by installing third-party add-ons or plugins. These add-ons are typically developed by independent developers or companies.

Important
Ensure that the add-ons are well-designed and tested, and that they integrate seamlessly with the core system to ensure optimal performance and security.

Jira and Confluence are good examples of add-on based systems that should be modeled as Environment Landscapes.

How It’s Modeled:

• An Environment Landscape represents the core system, including details such as Jira version, URL, license type, and number of users.

• Each installed app is represented as a Tier, used to track the app’s version, status, settings, owner, administrators, licensing status, and other relevant information.

Multi-Tenancy

Multi-tenant Environments serve multiple customers using a shared Application instance, with isolated configurations and data.

In a Multi-tenant Environment, tenants are typically isolated from each other, meaning that one tenant's data cannot be accessed by another tenant. This is usually achieved through various means, such as data partitioning, virtualization, or access control mechanisms.

How it’s Modeled:

• Each tenant is modeled as an Environment Landscape, with unique status, attributes, URL, and other relevant details.

• The Tiers are used to track specific information such as license status, support tickets, bugs, configurations, and more for each customer.

Important

Hosting multiple instances of the same Application for different tenants WITHOUT any mutualized/shared resources is not considered multi-tenancy. In this case prefer modeling each tenant as an Environment (without Tiers) in Golive.

When Should You Not Use Tiers?

Avoid using Tiers in the following scenarios. Instead, use alternative modeling approaches better suited to the use case:

Multi-Market / Multi-Customer / Multi-Region

Multi-market applications serve customers across different markets, regions, or countries. These applications may offer:

• Different product variations.

• Localized pricing.

• Region-specific interfaces or shipping options.

Multi-market Applications are commonly used in e-commerce, where companies sell products or services to customers in different countries or regions.

Recommended Approach:

• Do not use Tiers to model each market, customer, or region.

• Instead, use a Single-select Attribute to list your customers, regions, or markets.

• Create dedicated Environments for each, using a naming convention that includes the customer, region, or market.

Tip
Include the customer, region, or market in the Environment name to easily distinguish Environments that share the same Application and Category.