ARCHITECTURE-SPECIALIST-11 Practice Questions

The OutSystems Architecture Canvas is a foundational framework specifically created to guide the design of application architecture. It proposes a three-layer structure (End-user, Core, and Orchestration) for organizing modules within an application portfolio. This layered approach promotes the correct abstraction and isolation of components, leading to increased reusability, easier maintenance, and better scalability. The Canvas serves as a visual and conceptual tool for architects and developers to create a sound, loosely coupled, and well-structured application landscape.

A. framework to support Architecture Conventions for Modules in Outsystems: While the Canvas helps enforce conventions by classifying modules into layers, its primary purpose is the overall architectural design, not just the conventions themselves.

C. framework to support Architecture Design Process in Outsystems: The Canvas is a framework used within the design process to structure the application architecture. It is not the entire process, which also includes steps like discovery and validation.

1. OutSystems. (n.d.). Designing the architecture of your OutSystems applications. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/bestpractices/designingthearchitectureofyouroutsystemsapplications/

Reference Point: In the "The 3 Layer Canvas" section

the first sentence states: "The 3 Layer Canvas is a simple framework to design your application's architecture." This directly validates option B.

2. OutSystems. (n.d.). Validating your application architecture. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/bestpractices/architecture/validatingyourapplicationarchitecture/

Reference Point: The introduction discusses the Architecture Canvas as the basis for a "sound architecture design

" reinforcing its role as a design framework rather than a process or a set of conventions.

The ISO/IEC 25010:2011 standard, part of the SQuaRE series, superseded the older ISO/IEC 9126 standard for software product quality. The new model redefined some characteristics and added two new top-level ones: Security and Compatibility. While "Integration" is a crucial concept, it is defined within ISO/IEC 25010 as a sub-characteristic of Compatibility, alongside Interoperability. Therefore, Integration itself was not one of the main characteristics added to the model, making it the correct answer to the question of which option was not part of the top-level additions.

A. Compatibility was explicitly added as a new main characteristic in ISO/IEC 25010 to address how a product can exchange information and perform its functions while sharing the same environment or resources.

B. Security was the other new main characteristic introduced in ISO/IEC 25010, elevating its importance from being a sub-characteristic of Functionality in the previous standard.

1. OutSystems Official Documentation. Designing the architecture of your OutSystems applications

Version 1.1

March 2019. Page 11

Section "Non-functional requirements

" lists the eight quality characteristics from ISO/IEC 25010

explicitly including Security and Compatibility.

2. International Organization for Standardization (ISO). ISO/IEC 25010:2011 - Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. The standard's official abstract and scope define the eight product quality characteristics

which are: functional suitability

performance efficiency

compatibility

usability

reliability

security

maintainability

and portability. This confirms the addition of Security and Compatibility compared to its predecessor.

3. Al-Qutaish

R. E. (2010). Quality Models in Software Engineering Literature: An Analytical and Comparative Study. Journal of American Science

6(3). This academic paper analyzes the evolution of software quality models

detailing the transition from ISO 9126's six characteristics to the eight in the then-emerging ISO 25010 standard

highlighting the promotion and addition of Security and Compatibility. (Note: This paper discusses the draft standard

which was later formally published as ISO/IEC 25010:2011 with the same characteristics).

Storing a user's password in the device's local storage is a critical security vulnerability and is explicitly against best practices. Local storage is not an encrypted or secure container and can be accessed by other applications or malicious actors if the device is compromised. OutSystems recommends using secure, platform-specific storage mechanisms, such as the Keychain on iOS or Keystore on Android, for any sensitive information. This is typically achieved by using supported Forge components like the Key Store Plugin, which provides a secure API to store data. Authentication tokens, not raw passwords, should be stored for session management.

B. Encrypting sensitive data is a fundamental security best practice to protect data at rest, ensuring it remains confidential even if the device's storage is breached.

C. Using external identity providers (e.g., Google, Facebook) for online authentication and device-native methods (fingerprint, PIN) for offline access are recommended, secure, and user-friendly patterns.

1. OutSystems Official Documentation

"Mobile and Reactive App Security Best Practices":

Section: Protecting data: This section advises against storing sensitive information in local storage. It states

"For highly sensitive information

like access tokens

use a secure storage plugin available from the OutSystems Forge

like the Key Store Plugin... This will store the data in the device's Keychain/Keystore." This directly contradicts option A and supports the reasoning for its incorrectness.

Section: Authentication: This section recommends using external identity providers and also discusses patterns for offline authentication using a local PIN or biometrics

validating the practices mentioned in option C.

2. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications" e-book:

Chapter: 5. Security

Section: Mobile App Security (Page 70): The guide emphasizes

"Never store sensitive data

such as passwords or personal information

in the device’s local storage. Use secure storage plugins that leverage native device capabilities like the keychain." This reinforces that option A is not a best practice. It also discusses the importance of data encryption

supporting option B.

The scenario described in option B is architecturally incorrect for achieving a common, shared login flow. For components like a menu or login flow to be common and easily updatable across multiple applications, they must be defined in a shared, referenced module, such as a Custom Theme. A Custom Template is only used to create a new application; any subsequent changes to the template are not propagated to the applications already created from it. Therefore, placing a common login flow in a template would prevent centralized updates and break the "common" requirement. The other options describe valid, standard OutSystems architectural patterns for sharing UI components.

A. This is a valid scenario for an Intranet where a common authentication (SSO) is required, but each application has its own distinct navigation menu.

C. This correctly describes a pattern for fully independent applications. A custom template provides a consistent starting point, but each application then manages its own UI components without sharing.

D. This is the standard and most common pattern for a portal or a suite of enterprise applications, ensuring a fully consistent user experience by sharing both menu and login via a central theme.

1. OutSystems Official Documentation

"Share a Style Guide Across Apps": This document explicitly outlines the three common scenarios for sharing UI.

Scenario: Portal - Common Menu and Login: "To have a common menu and login for all your apps

define the Menu and Login blocks in the Theme of your Style Guide." This directly supports option D as a valid pattern and contradicts the implementation in option B.

Scenario: Intranet - Common Login

but own Menu: "To have a common login

but an app-specific menu

define the Login block in the Theme of your Style Guide. The Menu block should be defined in the app itself." This validates option A.

Scenario: Independent Apps - Own Menu and Login: "If you want to have a set of apps that are completely independent

with their own menu and login

you can create a custom app template." This validates option C.

2. OutSystems Official Documentation

"Create and use a custom screen template": This document clarifies the purpose of templates. It states

"A Screen Template is a starter for creating new Screens... When you use a template to create a new Screen

OutSystems copies the template's content..." This highlights that templates are for one-time creation

not for ongoing

shared dependencies

which is why option B is an incorrect pattern for a common login.

The Application Composition Process in OutSystems refers to the fundamental step of creating an application by selecting and grouping one or more modules (eSpaces or Extensions). This process packages the modules into a single deployable and versionable unit. Defining this composition is crucial as it establishes the application's functional scope, its development lifecycle, and how it is managed within the infrastructure. It is a core activity for organizing code and maintaining a sound architecture.

A. This option is logically invalid and nonsensical as it refers to a non-existent preceding statement.

---

1. OutSystems 11 Documentation

"Applications": "An application is a group of modules that support a business function. When you create a new application

you are creating a container for the modules that will make up your application." This source directly supports the concept of an application as a package or container for modules. (Source: https://success.outsystems.com/documentation/11/developinganapplication/servicestudio/applications/)

2. OutSystems 11 Documentation

"Validating your application architecture": "An application is a set of modules with its own life cycle

deployment

and ownership." This reference reinforces that an application is composed of a set of modules

which is the outcome of the composition process. (Source: https://success.outsystems.com/documentation/11/managingtheapplicationslifecycle/managetechnicaldebt/validatingyourapplicationarchitecture/)

3. OutSystems 11 Documentation

"Module": "A Module is a single unit of deployment of an OutSystems Application... Modules are created inside Applications." This defines the components (modules) that are packaged during the application composition process. (Source: https://success.outsystems.com/documentation/11/developinganapplication/servicestudio/module/)

In the context of OutSystems architecture, the term "OAPI" is likely used to refer to the internal Application Programming Interface of an OutSystems module, specifically a Service Module. The core component of this interface, used to expose reusable, non-breaking business logic and functionality to other modules within the same environment, is the Service Action. This provides a strongly-typed, compile-time-checked contract between modules. This is distinct from a REST API, which is a technology used to expose functionality over web standards (HTTP) primarily for external systems or decoupled front-ends.

B. REST API: A REST API is a specific type of web service interface for exposing functionality, not a component inside the fundamental, internal API of a Service Module. A REST API method typically calls a Server Action to execute its logic.

1. OutSystems Official Documentation

"Service Actions": "A Service Action is a public Server Action in a Service Module. It encapsulates a piece of business or integration logic and can be reused across different modules... Service Actions are the key element for building a service-oriented architecture." This source establishes the Service Action as the key element of a Service Module's reusable API.

2. OutSystems Official Documentation

"Designing the architecture of your applications"

The 4 Layer Canvas: In the section describing Core Services

it states: "They offer reusable business services... exposing a well-defined and non-breaking public API of Service Actions." This reinforces that the API of a Core Service module is composed of Service Actions.

3. OutSystems Official Documentation

"Expose REST APIs": "Expose REST APIs to make your application's data and functionality available to other systems." This document defines REST APIs as a mechanism for external exposure

distinguishing them from the internal

module-to-module communication facilitated by Service Actions.

A lack of architectural concerns directly leads to inherent, structural problems within an application portfolio. These include creating inflexible systems that are slow to change (A), developing unmanageable dependencies between modules (C), and implementing poor service abstractions where business logic is scattered and not reusable (D). These are all direct consequences of poor design.

Option B describes the action of AI Mentor Studio, a tool that detects and reports on technical debt, such as cyclic dependencies. The existence of the technical debt is the consequence of poor architecture; the tool's action of raising an alert is a separate, subsequent event for monitoring and analysis, not a direct outcome of the architectural flaw itself.

A. Inflexible and slow-moving legacy systems are a direct and common consequence of neglecting architectural principles, leading to high maintenance costs and slow adaptation.

C. Unmanageable dependencies are a primary symptom of poor architecture, where a lack of layering and modularity creates a "big ball of mud" that is difficult to maintain.

D. Poor service abstraction is a direct result of failing to properly isolate business concepts, leading to duplicated logic and low code reuse across the application portfolio.

1. OutSystems Official Documentation

"Designing the Architecture of Your OutSystems Applications

" Version 2.1

Page 6

Section "Why is a sound architecture so important?". This document explicitly lists the consequences of a lack of architecture: "The application portfolio becomes a 'big ball of mud' of interconnected applications and modules

with no clear boundaries or purposes... This leads to: Inflexible and slow-moving legacy systems... Unmanageable dependencies... Poor service abstraction." This directly supports that A

C

and D are consequences.

2. OutSystems Official Documentation

"AI Mentor Studio overview

" Section "What is AI Mentor Studio?". This source describes AI Mentor Studio as a tool that "analyzes your OutSystems applications to identify and help you pay back technical debt." This clarifies that the tool's function is to identify issues

distinguishing its action from the issues themselves.

3. OutSystems Official Documentation

"Code analysis patterns

" Section "Architecture". This page lists architectural findings that AI Mentor Studio detects

such as "Cyclic Dependencies" and "Side References between End-user modules." This confirms that the tool reports on the technical debt mentioned in option B

but the reporting is not the consequence itself.

The Extension Pattern refers to the use of an Extension Module, which is a specific type of Library module created in OutSystems Integration Studio. Its primary purpose is to extend the platform's native capabilities. This is achieved by either integrating with an external database, allowing its tables to be used as OutSystems entities, or by wrapping custom C# code and external libraries (.NET assemblies) into reusable Actions. This module then acts as a library, exposing this new functionality to other OutSystems applications.

A. This describes the Connector/Wrapper pattern, which is used to abstract and normalize an external API, not specifically to wrap external code or libraries.

B. This describes an event-driven synchronization pattern, a method for data replication, not for extending platform functionality with external code.

C. This describes the Cache-on-Demand (or Lazy Load) data integration pattern, which is a caching strategy.

D. This describes an Aggregation or Federation integration pattern, where a service acts as a broker for multiple external systems.

E. This describes the Abstract Core (or Summary/Detail) data integration pattern, another caching strategy focusing on summary data.

F. This describes the standard Core Service pattern for encapsulating an OutSystems entity and its business logic.

G. This describes the Sync Wrapper pattern, where synchronization logic is decoupled from the Core Service holding the replicated data.

H. This describes a direct integration pattern where no data is cached or stored locally in OutSystems.

J. This describes the Core Service with Local Replica pattern, a full data caching strategy.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications" Guide:

Section: Core Services > Integration Services: This section explains that Integration Services are used to connect with external systems. It states

"To integrate with an external database or to extend the logic with your own C# code

you must create an Extension Module." This directly supports the definition in option I.

Section: Caching external data: This section details the patterns described in options C

E

H

and J (Lazy load

Abstract Core

No cache

Full cache)

confirming they are distinct data caching strategies.

2. OutSystems Official Documentation

"Extend Logic with Your Own Code":

Introduction: This document explicitly states

"To extend the functionality of your OutSystems apps

you can create your own logic in C# and make it available in Service Studio... You do this by creating an Extension Module in Integration Studio." This validates that the core purpose of an extension is to wrap external code

as described in option I.

3. OutSystems Official Documentation

"Integrate with an External Database":

Introduction: This resource details the process of using Integration Studio to create an Extension Module that connects to an external database. It explains how this allows you to "use the tables and views in that database as Entities in your OutSystems application." This confirms the other key function of an Extension Module mentioned in option I.

The statement is false. According to the official OutSystems 3-Layer Canvas architecture, the Foundation layer is designed exclusively for non-business services. Its primary purpose is to provide reusable, non-functional logic and to abstract integrations with external systems. Core business concepts and their corresponding services (e.g., Customer, Product, Order) must be placed in the Core layer. Placing business services in the Foundation layer is considered an architectural anti-pattern as it breaks the intended abstraction and creates incorrect dependencies, leading to a monolithic and less agile application portfolio.

The "True" option is incorrect because it violates the fundamental principle of separation of concerns defined by the OutSystems 3-Layer Canvas. The canvas explicitly segregates non-business, technical services (Foundation) from core business logic and entities (Core). This separation is crucial for ensuring reusability, maintainability, and loose coupling across the application landscape.

1. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" The 3-Layer Canvas

Foundation layer.

Reference: "The bottom layer contains all modules that provide reusable non-functional logic

and integration with external systems. These modules are the building blocks of your application portfolio... Examples of foundation modules are services to integrate with a legacy system

or a library with functions to handle complex security requirements." This source explicitly defines the Foundation layer for non-functional and integration purposes

not business services.

2. OutSystems Official Documentation

"Designing the architecture of your OutSystems applications

" The 3-Layer Canvas

Core layer.

Reference: "The middle layer contains modules that encapsulate the core business concepts of your application portfolio... Core modules provide reusable services and data around a business concept (e.g. Customer

Product

or Invoice)." This clearly designates the Core layer as the proper location for business services.

3. OutSystems Official Documentation

"Architecture Dashboard

" Code analysis patterns

"Incorrect Foundation dependency (IFD)".

Reference: "This finding is triggered when a Foundation module references a Core or an End-user module. Foundation modules should be independent of any business context to be truly reusable across all applications. Referencing a Core or an End-user module introduces a business context in a Foundation module." This technical enforcement rule confirms that Foundation modules must remain free of business context

which is embodied in business services.

The Base ECS (Expose, Consume, Synchronize) pattern, often referred to as the Integration Wrapper pattern, is a fundamental architectural structure for integrating with external systems in OutSystems. It mandates a two-module approach for abstraction and stability. The first module, the Connector, encapsulates all technical aspects of the integration, such as consuming a specific API and its data structures. The second module, the Core Service (or Wrapper), consumes the Connector and exposes a simplified, stable, and business-aligned API to the rest of the application portfolio, effectively hiding the complexity of the external system from the consumers.

A. This description focuses solely on the Connector module's role, which is only one half of the complete Base ECS pattern.

B. This describes the "Summary/Detail" caching pattern, a specific data synchronization strategy, not the fundamental architectural structure of the Base ECS.

C. This describes an advanced pattern where synchronization logic is decoupled into a third module, which is a variation, not the base pattern.

E. This describes an "Integration Broker" or "Gateway" pattern, which is used to abstract and orchestrate multiple external systems.

F. This describes a reactive synchronization method using a subscription or webhook model, which is a specific implementation, not the base pattern.

G. This explicitly describes the "ECS with Local Replica" pattern, a common variation that adds local caching, but it is not the base pattern itself.

H. This describes the functional behavior of a remote integration but omits the crucial two-module architectural structure that defines the pattern.

I. This describes the "Read-Through Cache" pattern, a specific on-demand caching strategy used when full synchronization is not feasible.

J. This describes the principle of exposing read-only entities, a best practice applied within the Core Service module, not the entire integration pattern.

1. OutSystems Documentation

"Architecture Patterns in OutSystems" Guide: The "Integration Wrapper" pattern is detailed

stating

"This pattern consists of two modules: a connector that encapsulates an external API with the input/output structures

and a wrapper that exposes a normalized API to consumers." This guide provides a diagram showing the Connector (ISV) and the Core Service (CS) wrapper

which directly corresponds to option D.

2. OutSystems Training

"Architecture of OutSystems Applications" Course Material: In the section on integration layers

the course explains the need to isolate external system complexities. It presents the pattern of having a dedicated Connector module and a Core Service module that acts as a wrapper to provide a stable API

insulating consumer modules from changes in the external system. This reinforces the two-module structure described in option D.

3. OutSystems Documentation

"Designing the Architecture of Your OutSystems Applications" White Paper: Section 3.3

"Integration Layer

" discusses abstracting integrations. It advocates for creating a "connector" to handle the technical protocol and a "core service" to expose a public

stable API

which aligns perfectly with the description in option D.