“Good Enough” Architecture Part 2
summary
Three cases show concrete failures and fixes: a multi-tenant e‑commerce system ships a 1GB Eclipse‑based IDE for customer customization that pleases neither big clients nor the long tail; a life‑insurance product uses Rational Rose model‑driven dev with a two‑week modeling window and Excel mappings, forcing biannual releases and chaotic attribute repurposing; a financial service accumulates duplicated stacks and a buggy proprietary C++ encryption lib that locks data to a dead platform. Lessons: favor simple, evolvable designs, avoid centralized bottlenecks, plan evolution.
AI-written summary · about
chapters (10)
- 0:00Intro
- 1:31First statement about architecture
- 2:33Second statement about architecture
- 3:22Third statement about architecture
- 4:46Architecture antipatterns
- 5:59Cases
- 6:11Case No. 1: E-Commerce retail provider
- 13:04Case No. 2: Large-scale insurance system
- 18:56Case No. 3: Financial services provider w/ independent brokers as clients
- 24:24Takeaways
related talks
33mFrom Enterprise Architecture to Software Design - Critical Thinking
29mFrom big to small and back again
57mSoftware Architecture: The Hard Parts
05mDesign and Architecture: Special Dumpster Fire Unit
49mCase study of a good enough architecture
01h 05mE-Commerce vs. Architecture!
45mGeneric or Specific? Making Sensible Software Design Decisions
25mBuilding Castles, Not Sandcastles: Strategies for Software Architecture Success