IT courses / architecture practice2026 studio programme
A supervised systems laboratory
See the boundary. Trace the request.
Learn to reason about distributed software through physical models, guided diagnosis and repeatable lab notes. Every module ends with evidence you can explain—not a memorised answer.
Choose the specimen that matches your current work.
The diagnostic suggests a starting module. It does not grade you or promise an outcome.
Suggested entry point
Module 01 — Baseline specimen
Begin with one stable request path and learn how to label observations before naming a cause.
Map the visible components.
Name one blind spot.
Write the next inspection.
Specimen 01Baseline topology
Station 02 / foundations
Arrive with working context, not perfect expertise.
Wumiselaro is for developers who can read code, use version control and explain a request at a high level. You do not need prior architecture certification.
Read a codebase
Follow functions, modules and configuration without needing every implementation detail.
Describe a request
Name where input enters, where state changes and where a response leaves.
Keep evidence
Record assumptions, observations and decisions in a short engineering note.
Isolate one layer without losing the whole system.
Interface layer / observation
Follow intent until it becomes a request.
Inspect validation, state transitions and the contract sent downstream. A polished screen cannot prove that the service path is healthy.
Capture inputMark transformationTrace the handoff
Station 04 / curriculum
Six modules move from observation to defensible change.
Each module combines a short briefing, a guided lab, an individual note and a review conversation. The sequence is fixed; the specimen difficulty adapts to your cohort.
Sequence 04Six supervised modules
Map components, users and external dependencies. Separate what you observed from what you inferred.
Lab
Trace one stable request
Evidence
Annotated topology
Compare intended ownership with actual data movement. Locate coupling that hides behind convenient interfaces.
Lab
Boundary pressure test
Evidence
Contract inventory
Read synchronous and asynchronous paths. Identify retries, queues, timeouts and hidden failure ownership.
Lab
Handoff reconstruction
Evidence
Sequence note
Inspect consistency, ownership and recovery. Explain why storage behaviour changes the user-facing outcome.
Lab
State divergence drill
Evidence
Recovery map
Design a reversible change and decide what should be measured before, during and after release.
Lab
Controlled refactor
Evidence
Verification plan
Present a recommendation, its limits and the evidence that would change your mind. Reviewers test reasoning, not confidence.
Lab
Decision defence
Evidence
Final case file
Station 05 / practicum
Three exercises turn the sequence into judgement.
Select an exercise to reveal the briefing. All three specimens remain visible so you can compare scope before choosing.
Service organ map / two sessions
Assign responsibility before proposing a split.
Map which team owns each contract, queue and data store. Then identify one dependency that creates operational ambiguity.
Deliverable
Ownership map and boundary proposal
Review question
What evidence would justify the split?
Instrument 08Feedback rounds
Station 06 / assessment
Evidence is reviewed in rounds, not reduced to a score.
Choose the evidence you can currently produce. The rubric shows what a reviewer would ask for next.
Round 01 / observation
Make the system visible before changing it.
Your reviewer checks whether another engineer can reproduce the path and distinguish observed behaviour from assumptions.
Label each source.
Record one uncertainty.
Keep the original baseline.
Feedback format: one written review, one live defence and one revision window.
Limit: completion records assessed work; it does not guarantee employment or promotion.
Station 07 / application desk
Build a practicum plan around the system you actually work with.
Tell us your role, current architecture and the decision you want to practise. We reply with a suggested starting module and current cohort options.
No matching studio question.Try a shorter term or clear the search.
Working developers, platform engineers, quality specialists and technical leads who already read code and want a more reliable way to reason about architecture. It is not an introductory programming course.
Professional experience helps, but years alone are not the gate. You should be comfortable following a request through code, reading logs and discussing trade-offs with another engineer.
Yes. Briefings, sandbox labs and reviews are available remotely. Live review windows are scheduled in advance because discussion and revision are central to the course.
A topology map, contract inventory, request sequence, recovery note, verification plan and final architecture case file. You control what can be shared outside the studio.
Reviewers assess whether your evidence supports the decision, whether limitations are visible and whether another engineer can follow the reasoning. There is no artificial leaderboard.
No. Wumiselaro provides structured practice, review and evidence of completed course work. Employment outcomes depend on your experience, performance, market conditions and employer decisions.
