D608 Data Processing, catalog number DTAN 6221, is the three CU course in the WGU Master of Science, Data Analytics covering the automation of data flow into and out of the components of an analytics system, including extract, transform and load concepts. It is the plumbing course, and plumbing is the part of analytics that nobody notices until the day it fails and every dashboard in the organisation is quietly wrong.
Correctness under repetition
A one off script that moves data from A to B is not what DTAN 6221 is assessing. The assessed property is correctness under repetition: the same job running every day, on data that changes shape without warning, produced by systems nobody told you about, with somebody's morning report depending on the result.
That reframing changes what belongs in a submission. Data quality checks stop being optional. Incremental loading stops being an optimisation and becomes a design question about how you know what is new. Schema change stops being a rare event and becomes something the design has to survive. And the transformation logic itself has to be documented well enough that a colleague can tell whether a surprising number is a bug or a fact.
The third scored theme is the shape of the flow. Extract, transform, load and extract, load, transform are different architectures with different consequences for cost, auditability and reprocessing. Choosing between them with a stated reason, rather than defaulting to whichever the tutorial used, is one of the more reliable ways a submission signals graduate level thinking.
Turning scored aspects into a section plan
The scoring detail lives in your Course of Study, not in the public catalog. Count the aspects there and treat that count as your outline. Each is scored on its own against a three point scale and each needs a 2, which means an elegantly engineered pipeline with no data quality section is a returned task.
Because much of the deliverable is code, mapping matters more here than in a written course. For each scored aspect, decide in advance whether it is satisfied by narrative, by artefact, or by both, and make sure the narrative names the artefact. A validation routine buried at line 340 of a script scores nothing if the report never mentions it.
The word budget, worked. Suppose six scored aspects and about 1,800 words of narrative outside the code. Hold 140 words for an opening naming the source systems and the destination, and 110 for a close. That leaves roughly 1,550, near 260 per aspect. Then take 50 words from each of three descriptive aspects and hand 100 to the data quality aspect and 50 to the error handling aspect. Those two are consistently the thinnest sections in submitted work and consistently the easiest to strengthen.
A structure that fits a data processing submission
Directions win where they specify a structure. Where they do not, this order matches how processing aspects tend to be written.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Sources and destination | Each source system, its format, its refresh rate, its owner, and where data lands | Ownership and refresh rate are often omitted and always relevant |
| Flow design | The chosen pattern, the order of operations and why that order | Scored on reasoning; the choice between transform before or after load matters |
| Transformations | Each business rule stated in plain language beside its implementation | Rules described only in code are invisible to a business reader |
| Data quality | The checks, their thresholds and what happens when one fails | The section that most often decides the outcome |
| Incremental logic | How the job knows what is new, and how reprocessing is handled | Full reloads described as incremental are a common inaccuracy |
| Orchestration and error handling | Scheduling, dependencies, retries, alerting and recovery | Checked for whether failure was designed for or ignored |
| Validation | Evidence the output matches the source, with row counts and control totals | Numbers here are more persuasive than any description |
Write the business rules in plain language first, then implement them. Rules extracted from finished code after the fact tend to be described in terms of what the code does rather than what the business means, and the difference is visible.
Evidence craft for a pipeline
The persuasive evidence in a processing task is arithmetic: counts, totals and comparisons that show the data survived the journey.
- Report row counts at every stage. Source, post extract, post transform, loaded. Discrepancies explained are fine; discrepancies unmentioned are not.
- Use control totals on numeric columns. If a sum changes between source and destination, either explain it or fix it.
- Show a real record end to end. One row traced through every transformation demonstrates the logic better than a page of prose.
- Cite the source system documentation for any assumption about format, encoding or delivery timing.
- State what you did with rejected records. Silently dropping bad rows is the most common data quality failure and the easiest to catch.
- Use APA for external sources and keep quotation short.
The habit that marks out a strong submission is stating the freshness guarantee: how out of date the destination can be at worst, and what a consumer should assume about it. Analytics teams argue about this constantly in practice, and answering it unprompted reads as experience.
What separates Competent from a submission sent back
Independent aspect scoring keeps returns local, and in this course they concentrate on quality and failure handling rather than on transformation logic.
- Every business rule appears in plain language as well as in code.
- Data quality checks have thresholds and defined consequences, not just descriptions.
- Rejected or failed records have a documented destination and someone who reviews them.
- The incremental strategy is stated precisely enough that a reader could reimplement it.
- Validation shows numbers that match, or explains precisely why they do not.
Performance assessment work can be revised and resubmitted with no grade penalty, so the cost of a return is time in the queue. With six month flat rate terms, that time is the whole budget and a rebuild in a code heavy course is an expensive way to spend it.
Six mistakes that cost time in D608
- Silent row loss. A join that quietly drops unmatched records is the single most common defect in student pipelines, and row counts expose it immediately.
- Transformations that only exist in code. A business reader cannot audit a rule they cannot read.
- Calling a full reload incremental. If the job truncates and reloads, say so and justify it. It is often the right choice at coursework scale.
- No handling for schema drift. A new column or a renamed field will happen, and a design that assumes otherwise is fragile by construction.
- Timezone and encoding assumptions left unstated. Both cause errors that survive validation and surface weeks later.
- Skipping validation because the job ran. Running is not the same as correct, and the difference is what the course is teaching.
Building the data quality section that passes
If one section decides D608 submissions, it is data quality, and it is worth building deliberately rather than adding at the end. Four categories of check cover almost everything a rubric looks for.
Completeness asks whether everything that should have arrived did. Row counts against the source, expected file arrival, and a check that no partition is empty when it should not be. Validity asks whether each value is a legal value: types, ranges, permitted category codes, dates that are not in the future. Consistency asks whether the data agrees with itself and with other systems: totals that reconcile, foreign keys that resolve, a customer count that has not doubled overnight. Timeliness asks whether the data arrived in time to be useful, which is the check most often missing entirely.
For each check, three things have to be written down: the threshold at which it fails, what the pipeline does when it fails, and who is told. A check with no threshold is an observation. A check that logs a warning nobody reads is decoration. The version that earns credit stops the load, quarantines the batch, and alerts a named owner, and it takes one short table to document.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: business rules written in plain language beside their implementation, a data quality section with thresholds and consequences, an incremental strategy stated precisely, and validation evidence with real numbers. Plus a walkthrough so you can defend the pipeline in your own words.
D608 is upstream of the analytics work in the specialization, which makes clearing it early worth more than three competency units suggest. Terms run six months at a flat rate, so sequence matters as much as effort.
Questions students ask about D608
Is D608 the same course as DTAN 6221?
Is D608 the same thing as the deployment course?
Can you write the pipeline code for my submission?
Where D608 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.