Skip to content

Logical Architecture

The logical architecture of IFS Cloud defines how the complete solution is broken down to its constituent parts. Understanding the logical architecture and the terminology within it is helpful when performing solution administration, tailoring, as well as development.

There are several perspectives to the logical architecture such as architectural tiers, how tailoring is enabled and separated from standard IFS Cloud through the Layered Application Architecture (LAA), and the principle of grouping everything into components.

Architectural Tiers

The picture below illustrates the main architectural tiers of IFS Cloud. Each tiers contains a number of models such as entities and projections. Models are expressed using the Marble low-code Domain Specific Language (DSL), complemented with business logic code. While some models (e.g. pages) are mainly declarative and light on code, others (e.g. utilities) contain almost exclusively code.

Logical Architecture of IFS Cloud

The purpose and main content (non-exhaustive list) of each tier is:

  • Presentation tier contains the elements that make up the user experience for IFS Cloud. The bulk consists of thousands of pages for IFS Cloud Web and hundreds for IFS Cloud Mobile. There are also Lobby pages, elements and data sources. Other user experiences such as add-ins for Microsoft Office are also part of this tier.
  • API tier contains projection models that define APIs to be used by pages, by integrations, and more. Each API contains a number of entity sets and/or actions grouped together for a purpose. While projections mainly expose entities and actions defined in the business logic tier, some of them add purpose-specific business logic such as extra access rules or validations. The API tier also includes information sources and analysis models intended for reporting as well as extraction of data for reporting and analytical purposes.
  • Business logic tier contains thousands of entity models as well as utilities. An entity model combines the information modeling (attributes, relationships) of business entities such as customers, orders, order lines, with much of the logic that operates on those entities. For example logic to perform validations, calculations and state transitions. This is similar to the principles of object oriented development. Business logic that doesn't naturally belong to any entity is placed in utilities, i.e. logical groups of business logic for a given purpose.
  • Storage tier consists of the tables used to store entity data along with any indexes etc. to make the storage model efficient and performant. Storage tier also holds other types of storage, such as binary or large-object storage.
  • Platform tier contains platform services such as "identity and access management", "cloud file storage", "report formatting" and "machine learning". The platform tier also contains a number of framework services which essentially are capabilities/SDKs/frameworks used when developing business logic, APIs, user experiences and so on.

All models are grouped into components across tiers by how they contribute to a complete capability.


Only the presentation tier and API tier are accessible to end users and other software in a running IFS Cloud deployment. Effectively there are https entpoints for the various user experiences as well as RESTFul OData APIs for the projections, along with some specialized https based APIs for other tasks.

Layered Application Architecture (LAA)

IFS Cloud is implemented according to the Layered Application Architecture (LAA), where each layer builds on the previous. For example, changes applied in the personalization layer takes precedence over those in the configuration layer, which takes precedence over those in the customization layer etc. The principles of LAA cater for separation of concerns and responsibilities, and also enables customers to tailor the customer solution in a non-intrusive way, making future updates easier to apply.

In LAA the following layers are defined

Layer Purpose Responsible Consists of
Personalization Keep personal preferences such as bookmarks and saved searches. End user Settings stored in the users profile
Configuration Customer solution tailoring through configuration, such as new lobby elements, workflows, page layout designs. Customer Meta-data stored in IFS Cloud itself, with an export of the same stored in the customer solution repository.
Customization Customer solution tailoring by extending on the inside to add more capability or override existing business logic and/or pages in the user experience. Customer Code stored in the customer solution repository
Core application The standard IFS Cloud software as delivered provided from IFS IFS Code stored in the master release repository
Core platform The standard IFS Cloud software as delivered provided from IFS IFS Pre-built artifacts (e.g. containers), code templates, tools, and code stored in the master release repository.

Changes in the personalization and configuration layer can take effect immediately as the changes are made. However, often configuration changes go through a staging step where the changes are first prepared and then “published” to take affect for all users. Neither of these require any downtime.

Changes in the code layers customization and core application require an applications build, delivery, and installation of delivery into deployment to take place. The delivery installation may require a short downtime.


Some components are exempt from the ability to use the customization layer, i.e. to add or override the underlying layers. This applies mainly to components that contains parts of the IFS Cloud platform iself. Read more about restricting customization


Components in IFS Cloud group the logical building blocks (entities, projections, pages, etc.) and resulting deployable code into mid-size coherent capability areas such as "General Ledger" and "Accounts Payable". A component typically contains a few dozen up to a couple of hundred logical building blocks. Each component has a public interface towards other components, consisting of the sum of all public APIs in the building blocks inside that component.

This use of components enables composition of a solution at the capability level, allowing components to be selectively active (or not) in the customer solution depending on the customers' chosen solution set. Components also facilitate separation of concerns and thus a higher development velocity.

  • Components are the smallest installable (can be deployed and activated) units of IFS Cloud. A component is either deployed in its entirety or not at all.
  • By default in an deployment all, or almost all, components are deployed. However only those components marked as active in the customer solution set (as specified in the solution set file) are activated and thus possible to use for the customer.
  • A component may be dependent on other components. For example, if the Invoicing component might be dependent on the Accounts Payable component. The interfaces between components are well defined and stable (not likely to change frequently).
  • Component dependencies may be static or dynamic. In a static dependency the dependence component must be active in orrder for the dependent component to work. In a dynamic dependency the dependent component will work regardless of whether the dependency component is active or not, with the logic of dependency component being involved at runtime if it is active.

End users typically are not aware of, nor need to care about, the component concept. While it has some relevance for Administrators, it's main use is in the Development and Deployment processes.