OutSystems Architecture Specialist (O11) common mistakes
OutSystems Architecture Specialist (O11) · Understand the traps and how to avoid them.
Treating the four layers as a naming convention and placing screens, server actions, and entity references in the same module, then justifying it because 'the canvas is organized'.
Candidates memorize the layer names (End-User, Core, Foundation, Library) but never internalize the dependency direction, so they classify modules by what they contain rather than by who is allowed to reference them.
What to do instead
For each module in a scenario, write down its allowed consumers and its allowed dependencies before answering. A module that exposes screens must not be referenced by Core or Foundation modules; a Core module must not reference another Core module's public actions unless the dependency is explicitly drawn in the design. Practice redrawing a given module map as an arrow diagram and rejecting any arrow that points upward.
Recommending a single 'shared' Core module that holds every entity and every public action so that 'everything can talk to everything', and calling that reuse.
Reuse is taught as 'put it in Core', and candidates conflate reuse with centralization. They miss that a single Core module becomes a deployment bottleneck and a coupling point that forces every consumer to redeploy together.
What to do instead
Split Core by business capability (for example Orders, Customers, Billing), each owning its own entities and exposing only the actions consumers need. When a scenario shows many consumers, ask whether the shared module changes for different reasons; if yes, it is two modules. State explicitly in your answer which capability owns each entity and which module is allowed to write it.
Answering scalability questions with 'use more front-ends' or 'add a load balancer' without stating what must be stateless, what is stored where, and which tier actually becomes the constraint.
Candidates reach for infrastructure vocabulary as a shortcut and skip the OutSystems-specific mechanics: session state, the separation of End-User from Core, and the fact that scaling a front-end does not relieve a saturated database.
What to do instead
Structure every scalability answer as: identify the bottleneck tier, state the OutSystems mechanism that addresses it (stateless front-ends behind a load balancer, asynchronous processing via BPT or timers, caching of reference data, read/write separation at the database), and name the trade-off. If you cannot name the bottleneck, say the measurement is missing rather than guessing.
Moving heavy work into a screen action or a synchronous server action to 'keep it simple', then being surprised when the design is marked as not scalable.
The candidate optimizes for the happy path of a demo rather than for concurrency and request duration. Long-running synchronous work ties up front-end threads and makes timeouts and retries behave unpredictably.
What to do instead
Classify each process in the scenario by duration and by whether the user must wait. Anything that calls an external system, processes batches, or can exceed a normal request should be a BPT process or a timer with explicit error handling and idempotency. In your answer, state where the process runs, how failure is retried, and how the user is informed.
Designing the module map without regard to how it will be deployed, then proposing a deployment plan that contradicts the module dependencies drawn earlier.
Lifecycle and design are studied as separate topics, so candidates answer each question in isolation and produce internally inconsistent solutions across the exam.
What to do instead
Before finalizing any architecture answer, derive the deployment units from the dependency graph: modules that must be published together form a deployment unit, and independent capabilities should be separable. Check that your stated deployment order respects the arrows you drew. If two answers in the same scenario would deploy different module sets, revise one.
Ignoring the impact of a change: recommending that a widely consumed Core module's public action signature be altered, or that an entity attribute be removed, without discussing consumers and versioning.
Candidates focus on making the current requirement work and treat published modules as freely editable. They do not consider that consumers may be in different applications or environments and cannot all be republished at once.
What to do instead
For any change to a shared module, list its consumers and classify the change as compatible or breaking. Prefer additive change (new action, new optional attribute) and deprecation over modification. Where a breaking change is unavoidable, describe the transition: new version, parallel support period, migration of consumers, then removal.
Treating the architect role as 'the person who draws the diagram and approves', and the developer role as 'the person who implements what the architect decided', with no mechanism for feedback in either direction.
Candidates answer role questions with generic job-description language instead of the autonomy model the exam tests: the architect sets constraints and boundaries, the developer owns decisions inside those boundaries and escalates when a boundary must change.
What to do instead
Frame answers around decision rights: name which decisions belong to the architect (layer boundaries, cross-module contracts, shared entity ownership, non-functional targets), which belong to the developer (internal implementation, local naming, action decomposition within a module), and the escalation path when a developer needs to cross a boundary. Show that constraints are documented and reviewable rather than imposed verbally.
Assuming a team can work independently because the modules are separate, while the modules still share writable entities or call each other synchronously in both directions.
Candidates equate physical separation with autonomy. They miss that shared write access and circular runtime dependencies force coordination on every change regardless of who owns which module.
What to do instead
Test autonomy by asking whether team A can publish without team B. If not, identify the coupling: shared entity ownership, a bidirectional dependency, or a shared deployment unit. Resolve it by assigning a single owner per entity, breaking cycles with an event or an intermediate module, and aligning deployment units with team boundaries.
Answering with a definitive architecture verdict on a scenario that lacks the information needed to decide, instead of stating what is missing and what would change the recommendation.
Exam pressure pushes candidates toward a confident single answer, and they do not practice recognizing under-specified scenarios where the expected response names the missing inputs.
What to do instead
Before committing, list the facts the decision depends on: expected load, number of consumers, team size, change frequency, latency tolerance, data volume. If a fact is absent, say so and give a conditional recommendation ('if load is under X, a single Core module suffices; above it, split by capability'). This demonstrates judgment rather than guessing.
Memorizing layer names and pattern labels but being unable to explain, for a concrete requirement, why a given placement is correct and what breaks if it is moved.
Candidates prepare by recalling vocabulary rather than by rehearsing the reasoning chain from requirement to placement to consequence, so they cannot answer 'why' or 'what if' variants of familiar questions.
What to do instead
For each pattern you study, write three sentences: the requirement it serves, the rule that forces the placement, and the failure that appears if the rule is violated. Practice taking one requirement and producing the module map, the dependency arrows, the deployment units, and the ownership assignment as a single coherent answer.