OutSystems Architecture Specialist (O11) study plan
OutSystems Architecture Specialist (O11) · Give each week a clear focus.
8 weeks · About 7 hours per week
OutSystems Architecture design fundamentals
Map the OutSystems layered canvas (End-User, Core, Foundation, Library, IS, Theme) and state the dependency rules that each layer enforces
Distinguish modules, module references, server actions, and public elements so you can justify why a given element belongs in Core versus Foundation
Classify ten common business capabilities into the correct layer and defend each placement with a coupling argument
Explain the difference between a module reference and a service reference, including when a service reference is mandatory
Your checkpoint
A one-page layered reference diagram plus a table of ten capabilities with layer placement and a one-sentence justification per row
OutSystems Architecture design fundamentals
Apply abstraction and encapsulation rules to decide what a Core module exposes versus hides behind public server actions
Design a reusable Foundation module contract that has no upward references and document its public interface
Identify and eliminate a circular dependency scenario by introducing an intermediary module
Differentiate strong versus weak entity relationships and choose exposure patterns that avoid leaking entity models upward
Your checkpoint
A written module contract for one Foundation module and one Core module, including exposed actions, exposed entities, and a dependency justification list
OutSystems Architecture design fundamentals & Scalable architecture design
Derive a scalability design from a stated non-functional requirement set (concurrent users, peak load, response targets)
Separate synchronous request paths from asynchronous work and place background processing in dedicated modules
Choose where to cache reference data and where caching would break consistency guarantees
Design a multi-tenant data model option (single database with tenant key versus per-tenant isolation) and justify the trade-off
Your checkpoint
A two-page scalability design brief for a sample application covering module decomposition, sync versus async boundaries, and caching decisions
Scalable architecture design
Plan horizontal scalability by identifying stateful patterns that prevent adding front-end servers
Design a database access strategy that avoids chatty queries and N+1 access patterns across module boundaries
Specify an integration pattern for an external system, including timeout, retry, and failure handling behavior
Evaluate when to split a module into a separate application or service to isolate load
Your checkpoint
An integration and data access specification for one external dependency, including a failure-mode table and a decision record on module splitting
Scalable architecture design & Application lifecycle efficiency and health
Define environment promotion paths (Development, Quality, Pre-Production, Production) and what configuration must differ per environment
Design a deployment checklist that catches broken references and missing dependencies before promotion
Establish a versioning and tagging convention for modules and applications that supports rollback
Identify lifecycle inefficiencies such as oversized deployments or unnecessary full republishes and propose a fix for each
Your checkpoint
A deployment readiness checklist plus a versioning convention document that a team could adopt unchanged
Application lifecycle efficiency and health
Interpret application health signals and separate architecture-caused incidents from code-caused incidents
Design a monitoring and alerting plan that covers integration failures, slow queries, and background job backlog
Set up a technical debt register with impact and effort scoring, and prioritize the top five items
Propose a refactoring sequence that reduces dependency violations without breaking running applications
Your checkpoint
A technical debt register with at least ten scored items and a sequenced remediation roadmap covering two quarters
Architecture roles and responsibilities (developer/architect autonomy)
Distinguish the architect's responsibilities from the developer's and define decision rights for each
Write an architecture decision record format and apply it to one real trade-off from earlier weeks
Design a review process that lets developers proceed autonomously while catching layer and dependency violations
Explain how to coach a developer through a design disagreement without overriding their ownership of the module
Your checkpoint
One completed architecture decision record plus a lightweight design review process description with entry and exit criteria
OutSystems Architecture design fundamentals & Scalable architecture design & Application lifecycle efficiency and health & Architecture roles and responsibilities (developer/architect autonomy)
Consolidate all prior deliverables into a single architecture handbook outline
Re-derive the layered design, scalability decisions, and lifecycle plan for a new scenario without notes
Practice justifying trade-offs verbally in short written answers to simulate exam reasoning
Close remaining knowledge gaps by listing every concept you still cannot explain in two sentences
Your checkpoint
A consolidated architecture handbook outline with a gap list of unresolved concepts and a remediation note for each
Milestones
Week 2: You can place any named capability into a layer and justify it in under one minute without consulting notes
Week 4: Your scalability brief names at least three stateful patterns to remove and at least two async boundaries, each with a stated reason
Week 6: Your debt register contains ten scored items and your remediation roadmap orders them by risk reduction per unit effort
Week 8: You can produce a complete architecture outline for an unseen scenario in 45 minutes with no reference material