D780 Software Architecture and Design is banner number ITSW 5103 and three competency units in the School of Technology, at the graduate level. The catalog describes it as designing, analyzing and managing large-scale software systems and selecting among architecture types. Selecting is the operative verb. The course is built around choice under constraint, where several architectures would work, each fails differently, and the graded competency is being able to say which failure your context can afford.
Architecture is the part that is expensive to change
The working definition worth adopting early is that architecture is the set of decisions that would be costly to reverse. Which components exist, what each owns, how they communicate, where state lives, and what crosses a process or network boundary. Those choices constrain everything built afterwards, which is why they get their own course and why the course is about judgment rather than technique.
Architecture types are the vocabulary. Layered, client and server, pipe and filter, event driven, service oriented, microservices, and the modular monolith that sits between several of them. Each has a shape, a set of conditions it suits, and a characteristic failure. Layered architectures are simple to reason about and become slow to change when every feature cuts through every layer. Event driven designs decouple producers from consumers and make the overall flow hard to follow. A graduate submission that lists styles without naming their failure modes has covered only half of each one.
Analysis is the second competency the catalog names. Evaluating an architecture means confronting it with scenarios, particularly the changes it will have to absorb and the failures it will have to survive, and seeing which decisions hold. Deciding by preference is the undergraduate move; deciding by scenario is what this course wants.
Managing large-scale systems is the third strand. Architecture decision records, keeping the documented design honest against what was actually built, and the reality that architecture erodes when nobody maintains the boundaries. Aspects that ask about evolution or governance are asking about this.
Turning scored aspects into decisions and a word budget
Each rubric aspect at WGU is scored independently and needs a 2. In an architecture course the aspects usually correspond to decisions or to analyses of decisions, so map each row onto either a decision you will defend or a scenario you will run the design against.
Work the budget. Suppose eleven scored aspects and a paper near 2,300 words. Eleven into 2,300 is 209 each. Sort them. One aspect states the context and constraints, 250. Two are comparative analyses of candidate architectures, at 350 each, or 700. One is the recommendation with trade-offs, 350. Two are quality attribute analyses against the chosen design, at 250 each, or 500. One covers deployment or operational implications, 200. One covers evolution and governance, 200. Three are lighter, an introduction, a diagram reading and a conclusion, at 100 each, or 300. That comes to 250 plus 700 plus 350 plus 500 plus 200 plus 200 plus 300, which is 2,500, so trim one comparison to 280 and the attribute sections to 220 each, landing near 2,370 and then cutting the conclusion to 70 puts you at 2,340. The comparison and recommendation still hold nearly half the paper.
Draw the diagram before writing. A component diagram with the boundaries marked forces you to decide what talks to what, and half the paper is then description of a picture you can already see.
On the D780 architecture paper?
Send the aspects and the system context. You get a candidate comparison, the scenarios to test each one against, and a recommendation structure.
Architecture types, what they buy and what they cost
| Type | Suits | Characteristic failure |
|---|---|---|
| Layered | Stable domains, small teams, clear separation of concerns | Every new feature cuts vertically through all layers |
| Modular monolith | One deployable with enforced internal boundaries | Boundaries erode without governance and it becomes a single tangle |
| Client and server | Shared data with many consuming clients | The server becomes the bottleneck and the single failure point |
| Pipe and filter | Data transformation in stages, batch processing | Poor fit for interactive work and awkward error recovery mid-pipeline |
| Event driven | Loose coupling, many reactions to one occurrence | No single place shows the flow, and ordering and duplication become real problems |
| Service oriented | Reuse across an organization with shared contracts | Contract governance overhead and shared infrastructure coupling |
| Microservices | Independent scaling and independent deployment by separate teams | Distributed failure, data consistency across services, operational burden |
The third column is what makes this a decision table rather than a glossary. Recommending a type without naming what it costs leaves a justification aspect half answered.
Diagrams, decision records and graduate sourcing
Architecture is communicated in views, and one diagram cannot carry all of them. A context view showing the system and its neighbors, a component view showing the internal parts and their dependencies, and a deployment view showing what runs where answer different questions, and mixing them into one picture produces something no reader can use. Label each view with what it shows and what it deliberately omits.
Decision records are the artifact that graduate aspects about governance are usually looking for. Each one names the decision, the context that forced it, the options considered, the choice and its consequences. Half a page each, and they are what a future engineer needs when they ask why the system is like this.
For sources, the established architecture texts, published evaluation methods and peer reviewed work on architectural styles are the strong material, cited in APA where your program requires it. Engineering blog posts from organizations describing their own systems are useful as experience reports and should be labeled as such rather than treated as general findings. Where you claim a style suits a condition, cite the source that supports the claim or ground it in a scenario from your own case.
What clears at this level
WGU records Competent or Not Competent with no letter grades and no ordinary grade point average, and a performance assessment that misses an aspect can be revised and resubmitted without penalty. The cost is time inside a six month flat rate term, which at graduate level usually means the second course you were carrying.
Papers that clear take the constraints seriously. They state team size, expected load, consistency requirements, regulatory conditions and operational capability, then choose an architecture those conditions support. They compare at least two candidates properly rather than presenting one and dismissing another in a sentence. They state what the recommendation gives up and under what change they would revisit it.
Returns come from three habits. Choosing microservices because the term is current, without an organizational or scaling condition to justify the operational cost. Diagrams that mix views so nothing can be read cleanly. And quality attributes discussed as adjectives rather than as scenarios with measures, which leaves the analysis aspects unsupported.
Seven mistakes that cost D780 students time
- Recommending by fashion. A style has to be argued from conditions in your case, not from its popularity.
- One diagram for everything. Context, components and deployment are separate views and merging them makes all three unreadable.
- Comparing one real candidate against a straw man. The rejected option deserves its best case, or the comparison proves nothing.
- Ignoring operational cost. Distribution buys independence and charges for it in monitoring, deployment and failure handling.
- Skipping data. Where state lives and how consistency is maintained is an architectural decision, and papers that discuss only components skip it.
- No decision records. Governance and evolution aspects are answered by records, and reconstructing them at the end produces a rationalization rather than a rationale.
- Treating the team as unlimited. An architecture that needs four teams to operate cannot be run by six people, and a design that outruns the organization that owns it fails in a way no diagram will show.
How we work on this course
Support for D780 is comparison and defense. Send the scored aspects and the system context and you get a candidate set with the failure modes named, the scenarios to test each design against, a view plan so your diagrams read cleanly, decision records for the choices your aspects will ask about, and a model paper in the register WGU graduate evaluators expect. Where an objective assessment is part of your course, our work is preparation only. Objective assessments are proctored, we never sit or assist during one, and we never ask for or touch portal credentials.
Terms are six months at a flat rate at graduate level as well, so what a course costs is the share of the term it takes. Architecture papers are among the ones that shrink most when the comparison is built before the writing.
Three questions D780 students ask
Is D780 the same course as ITSW 5103?
How is architecture different from design in this course?
Do I need to build anything for D780?
Where D780 sits in WGU's programs
The July 2026 catalog places this code in 6 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.