Why a “Big Mud Ball” Can Be a Good Architecture – Insights from a Former Google/AWS Architect

1. Distinguishing Bad and Good Architects

Gregor says a good architect makes everything run smoothly without anyone knowing why, while bad architects pile on buzzwords like “must be cloud‑native” or claim absolute authority over component counts. The core principle is: architects should make others smarter, not try to be the smartest.

2. Reducing Risk as the Architect’s True Value

He frames the architect’s role as risk management. By foreseeing and mitigating risks—whether scalability, security, or business impact—an architect delivers tangible monetary value. He contrasts the “golden design” myth with real‑world risk types that differ across domains such as finance, user adoption, and revenue.

3. Simplicity vs. Complexity in Large‑Scale Systems

Complexity is inevitable in distributed or serverless platforms (retry storms, back‑pressure, idempotency). The advice is to keep designs as simple as possible without oversimplifying, and to understand the inherent complexity of the platform rather than trying to eliminate it.

4. Solving Technical Disagreements Without Arguments

Instead of dictating answers, an architect should frame the solution space and build a shared decision‑making framework. He illustrates this by expanding the binary “monolith vs. micro‑services” choice into four quadrants, turning a debate into a constructive discussion.

5. Using Paper and Pen for Architecture

Visual sketches eliminate ambiguity that text cannot. Simple drawings clarify relationships, expose hidden assumptions, and help teams converge on a common view, especially when discussions stall or critical decisions are needed.

6. Alternating Left‑Brain and Right‑Brain Thinking

Effective architects switch between structured logical analysis and creative visual thinking. Pair‑programming, mentorship, and iterative sketching help surface missing dimensions and improve communication.

7. The “Architect Elevator” – Connecting Code and Strategy

When presenting to decision‑makers, combine a compelling story or striking visual with solid technical details. This dual capability makes the architect’s influence memorable and actionable.

8. The “Big Mud Ball” as a Viable Architecture

Although often dismissed, a “big mud ball” architecture—quick, cheap, low‑skill‑requirement—can be the right choice under tight deadlines or limited resources. The trade‑off is higher long‑term maintenance cost, but it may be the most pragmatic short‑term solution.

9. AI‑Generated Architecture Is a Dangerous Trap

Relying on LLMs to produce architecture documents without adding personal insight reduces the architect’s value. The tool’s output should be a starting point, not the final artifact; otherwise the architect risks being replaced.

10. Maintaining Technical Sharpness

Architects must continuously update hard skills, stay aware of outdated heuristics, and build reliable networks for rapid knowledge exchange. Over‑reliance on social media is discouraged; direct mentorship and real‑world practice are preferred.