ODC Architecture Specialist common mistakes
ODC Architecture Specialist · Understand the traps and how to avoid them.
The candidate draws a module diagram that violates canvas dependency direction - a Foundation or Library module referencing a Core service module, or a UI module holding business rules and entity updates - then selects answers consistent with that diagram. They can recite the layer names but never apply them as a constraint on references.
The canvas is learned as a set of labelled boxes for a diagram question rather than as a compile-time reference rule that the platform enforces when modules are published. Candidates answer the definition question correctly and then reason freely about references in scenario questions.
What to do instead
Before choosing an option, list every module in the scenario and write down its outgoing references. Apply one test to each: does the arrow point toward the more reusable, less context-specific module? Reject any option that makes a Foundation/Library module depend on Core, or that puts orchestration and business rules in an End-User module.
The candidate reasons about ODC using OutSystems 11 on-premises constraints - assuming a separately administered deployment controller, direct database access for tuning, server-level configuration, or environment infrastructure the team must size and maintain - and eliminates the correct answer because it 'can't be done in the platform'.
Most available study material, blog posts, and hands-on experience predate or ignore ODC's cloud-native model, so the mental model is inherited from a product with a very different operational surface.
What to do instead
Anchor every architecture decision on the ODC model: a fixed set of stages with isolated data, apps built in ODC Studio and managed through ODC Portal and ODC CLI, managed infrastructure you do not size or administer, and no direct database or server access. When an option assumes infrastructure ownership, treat that as the signal it is wrong.
The candidate decomposes the solution one module per screen or per menu item, duplicating validation and entity updates across those modules, and calls the result 'modular'.
Screens are the most visible unit of the requirements document and the easiest thing to map one-to-one onto modules, so the decomposition looks complete and tidy without any domain analysis behind it.
What to do instead
Decompose by business capability first: name each bounded context, assign ownership of its entities and rules to exactly one module, and only then add UI modules that orchestrate those capabilities. A quick check is that no business rule or entity write appears in more than one module.
The candidate marks almost every entity and action as public 'so anything can reuse it', producing a mesh of modules with two-way references and cyclic dependencies, and then picks an option that depends on that mesh being publishable.
Exposing things feels harmless and generous in the moment, and the candidate optimises for the immediate integration question instead of the long-term coupling cost that the exam is actually probing.
What to do instead
Default to private and expose only the contract another module genuinely needs - service actions rather than raw entities, a narrow public surface that can be versioned. Verify the proposed design is acyclic and that no two modules need to reference each other.
The candidate designs integrations as direct database connections, linked servers, or file drops, and hardcodes endpoint URLs and credentials inside the module logic.
Enterprise integration background leads to database-level or ESB-style patterns, and hardcoded values work in a development stage so they never surface as a problem during hands-on practice.
What to do instead
Model each external system as a REST service in Integration Builder with a normalised internal model, keep base URL and credentials in per-stage configuration so the same app works across stages, and make timeout, retry, and error-handling explicit in the design answer.
The candidate assumes data moves with the application - expecting to copy production data down to test, promote a database alongside a deployment, or query across stages - and selects an option that relies on that.
On-premises habits and the phrase 'deploy the app' imply the database travels with it, and nothing in day-to-day development contradicts that assumption until a lifecycle question exposes it.
What to do instead
State explicitly in the answer that each stage has its own isolated data store and only application assets move between stages. Where the scenario needs data, plan seed/bootstrap logic, synthetic or anonymised test data, and in-app handling of reference data instead of data synchronisation.
The candidate treats ODC Portal roles as if they were the application's runtime roles - arguing that because a user is a developer or administrator in the portal they can call a privileged action or see restricted data in the app.
Both planes use the word 'role', and the portal is the first place a candidate encounters roles, so the two concepts collapse into one in the mental model.
What to do instead
Keep the two planes separate and say so in reasoning: platform/IT roles govern who can build, deploy, and administer; application roles govern what an end user can do at runtime. Derive application roles from business responsibilities and enforce them independently of anything configured in the portal.
The candidate secures a feature by hiding the button or protecting the screen, then treats the action behind it as safe - no role check inside the server action and no validation on an exposed REST endpoint.
The behaviour demos correctly: the restricted user genuinely cannot see the control. Candidates rarely test the underlying action directly, so UI-level hiding looks like a complete control.
What to do instead
Treat every public action and every exposed endpoint as an untrusted entry point and put the check inside it, with screen-level protection as a UX layer only. A useful self-check is to ask what happens if the caller invokes the action directly with a hand-crafted request.
The candidate stores per-user working state in session or in-memory variables and runs long, heavy processing synchronously inside a screen action, assuming the user's successive requests land on the same server instance and that the request can take as long as it needs.
A single-server mental model and OutSystems 11-era habits make in-memory state feel free, and synchronous processing is the simplest thing that works in a low-volume development stage.
What to do instead
Externalize state to the database or an explicit cache, make actions idempotent so a repeated or concurrent call is safe, and move long-running work to asynchronous or timer-driven processing with the user given a status to poll. For every stateful design, ask what breaks when two instances run the same logic at once.
The candidate treats lifecycle and CI/CD as operations trivia and leaves it until last - assuming each team gets its own development environment, that publishing shared modules is unproblematic, and that manual publishing is acceptable in the proposed design.
Lifecycle sits at the end of the syllabus and feels like tooling rather than architecture, so it gets the least study time even though the exam tests it through design scenarios.
What to do instead
Plan explicitly for a fixed set of stages and a shared development stage where several teams publish concurrently, version shared apps and modules so consumers can absorb change, automate promotion through ODC CLI, and include a dependency and impact plan for any change to a shared module in the answer.