D794 Computer Architecture and Systems, catalog number ICSC 5203, is the three CU graduate course in the WGU School of Technology offering a comprehensive examination of the design and development of computer systems and their evolution. It is the course that answers a question most working developers have quietly carried for years: why does the same code run at wildly different speeds depending on how the data is arranged.
Mechanism, then consequence
Architecture work is scored on whether you can explain a behaviour by naming the mechanism that produces it. Saying that a program is slow because of memory access is a description. Saying that it is slow because the access pattern strides across cache lines, so nearly every read misses and stalls the pipeline while a full line is fetched, is an explanation, and only the second can be acted on.
The mechanisms that carry most of the course are the memory hierarchy, pipelining and its hazards, branch prediction, caching and locality, parallelism at instruction and thread level, and the relationship between the instruction set and what a compiler can do. A graduate submission is expected to reason with these rather than to define them.
The evolution element in the description matters too, and it is more than history. Architectures changed in response to specific pressures: the growing gap between processor and memory speed, the power limits that ended clock rate increases and pushed the industry to multiple cores, and the return of specialised hardware for workloads general processors handle inefficiently. Writing about a design choice as a response to a constraint is what distinguishes an analysis from a timeline.
Turning scored aspects into a section plan
Scoring detail sits in your Course of Study rather than the catalog. Count the aspects and treat them as your outline, worded close to the rubric's own language. Each is scored independently on a three point scale and each needs a 2, so a thorough treatment of the memory hierarchy cannot rescue a thin section on parallelism.
Where a task involves measurement or simulation, name the artefact in the narrative and quote the relevant output rather than leaving it in an appendix.
The word budget, worked. Assume six scored aspects and about 1,900 words. Reserve 150 words for an opening that names the system or workload under examination and 120 for a close. That leaves near 1,630, about 270 per aspect. Then move 60 words out of each of two descriptive aspects into the aspect covering performance analysis and the aspect covering design trade offs. Describing a component is cheap; explaining why a designer accepted a cost is the graduate material.
A structure that fits an architecture task
Follow your task directions where they specify a shape. Where they do not, this ordering matches how architecture aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| System and workload | The architecture examined and the workload it is judged against | Performance claims are meaningless without a workload |
| Mechanism | The relevant hardware behaviour explained at the level of what actually happens | The core scored reasoning |
| Measurement or evidence | Timings, counters, simulation output or cited published results | Evidence with conditions attached, not assertions |
| Analysis | Why the numbers look as they do, in terms of the mechanism | Where explanation replaces description |
| Design trade offs | What the architecture gave up to gain what it gained | Every architectural feature costs something |
| Evolution | The constraint that drove the change, and what it enabled | Constraint driven narrative rather than chronology |
| Implications | What a developer should do differently knowing this | Connects architecture to practice; frequently omitted |
Anchor everything to a workload. An architecture is not fast or slow in general, and a submission that treats performance as a property of hardware alone will struggle with any aspect asking for analysis.
Evidence craft for systems work
Systems claims are easy to make and specific to verify, and the difference shows immediately.
- Report the exact hardware, including cache sizes where relevant, since the numbers only mean something against a configuration.
- Use published specifications rather than remembered figures, and cite them.
- Where you measure, repeat and report variation, because single runs on a general purpose machine are noisy.
- Distinguish theoretical peak from achieved throughput, and never present the former as the latter.
- Cite classic architecture literature where it applies; the foundational results in this field are stable and citable.
- Use APA throughout and keep quotation short.
Include a case where the intuitive answer is wrong. A loop that gets faster when it does more work, or an algorithm with worse complexity that beats a better one at realistic sizes, demonstrates architectural understanding more convincingly than any correct explanation of an expected result.
What separates Competent from a submission sent back
Independent aspect scoring means returns are narrow and specific.
- Every performance claim names a workload and a configuration.
- Behaviour is explained by mechanism rather than restated in different words.
- Trade offs are named for every architectural feature discussed.
- Evolutionary changes are tied to the constraint that forced them.
- The implications section says something a developer could act on.
Performance assessment work can be revised and resubmitted with no grade penalty, so a return costs calendar rather than standing. Terms run six months at a flat rate, and architecture rewards steady accumulation, so an early start beats a concentrated finish.
Six mistakes that cost time in D794
- Describing components instead of explaining behaviour. A definition of a cache is not an analysis of a cache miss.
- Performance claims with no workload. Fast is a relation between a machine and a task, never a property of the machine.
- Quoting peak numbers. Theoretical maxima are almost never achieved and presenting them as achieved is a substantive error.
- Ignoring the memory wall. Most modern performance analysis is about memory rather than about arithmetic, and submissions that focus on instruction counts miss it.
- History as chronology. Dates without the pressures that produced the changes answer no aspect.
- No practical implication. The value of architecture knowledge is what it changes about how you write code, and saying so is expected.
- Treating parallel speedup as proportional to core count. The serial fraction of a program sets a ceiling that no amount of additional hardware removes, and a submission that promises linear scaling has ignored the single best known result in the field.
Reasoning about locality, which is most of the course
If one idea in D794 repays extra attention, it is locality, because it explains more observed performance than any other single mechanism and it appears in almost every assessed discussion.
The starting fact is the gap. A value already in the fastest cache is available in a few cycles; one that has to come from main memory takes hundreds. That ratio means a program's speed is dominated not by how many operations it performs but by how often it has to wait for data, and it is why two implementations of the same algorithm can differ by an order of magnitude.
Temporal locality is the tendency to reuse the same data soon after using it, and it is why caches work at all. Spatial locality is the tendency to use data near what you just used, and it is why memory is fetched in lines rather than in words. A data structure that scatters related values across memory defeats the second, which is the usual explanation for a linked structure losing badly to an array despite identical asymptotic complexity.
The practical consequences are worth writing out because they are exactly what an implications aspect wants. Iterate in the order the data is laid out. Prefer contiguous structures where traversal dominates. Group fields that are used together rather than fields that are conceptually related. Block large operations so a working set fits in cache. Each of these is a design decision available to any developer, none of them requires special hardware knowledge to apply, and all of them follow from one mechanism explained properly.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: mechanism level explanations, measurement protocols with conditions stated, trade off analysis for each feature discussed, and an implications section a developer could act on. Where the course includes a proctored objective assessment, support is preparation only, never sitting it, and we never ask for portal credentials.
D794 underpins the systems and performance reasoning used across the graduate sequence. Terms are six months at a flat rate, so building this understanding early pays back in the courses that follow.
Questions students ask about D794
Is D794 the same course as ICSC 5203?
Do I need to write assembly for this course?
Can you take the proctored assessment for me?
Where D794 sits in WGU's programs
The July 2026 catalog places this code in 3 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.