Theory teaches you what architecture should look like. Case studies teach you what it actually looks like when real constraints, budgets and people get involved.
The scenarios below are composites: they combine patterns I and many other architects have seen repeatedly across organizations. Names and details are deliberately generic, but the problems and lessons are very real.
Case 1: The Integration Sprawl
Context. A growing retailer had connected its e-commerce platform, ERP, CRM, warehouse system and marketing tools over several years, each with direct point-to-point integrations built by different teams.
Problem. Every new channel took months. A change in the ERP broke six integrations. Nobody could confidently say where customer data came from.
Options. Keep patching; replace everything with a new integration platform at once; or introduce a layered API approach gradually.
Decision. Introduce System APIs for the most critical systems first (ERP and CRM), then Process APIs for customer and order, and move integrations over one by one.
Lesson. The first project was slower than building another point-to-point connection. By the fourth project, delivery time had dropped significantly because most capabilities already existed. Reuse pays off over a portfolio, not a project.
Case 2: The Three CRMs
Context. After two acquisitions, a company was running three different CRMs for different business units.
Problem. No single view of shared customers, duplicated licenses, and inconsistent sales reporting.
Options. Integrate the three CRMs; or consolidate onto one platform.
Decision. Consolidate onto one CRM platform in waves, by business unit, with an integration layer to keep the remaining CRMs in sync during the transition.
Lesson. The technology migration was the easy part. Agreeing on common processes and data definitions across three business cultures took much longer, and needed executive sponsorship to resolve.
Case 3: The Untouchable Legacy System
Context. A financial services firm relied on a decades-old core system that very few people still understood.
Problem. Every change was slow and risky, and the remaining experts were close to retirement.
Options. Big-bang replacement; or gradual strangler fig modernization.
Decision. Put an API layer in front of the legacy system, then move functionality piece by piece to new services, starting with the most frequently changed areas.
Lesson. Capturing the knowledge of the legacy experts early was as important as the new technology. Their involvement turned a risky program into a manageable one.
Case 4: The AI Pilot That Would Not Scale
Context. A service organization built an impressive AI assistant prototype for its agents.
Problem. In production, answers were inconsistent. The knowledge base was outdated, the assistant could not access case history, and security reviews stopped deployment.
Options. Tune the model further; or fix the foundations.
Decision. Pause the rollout, clean up and govern the knowledge base, expose case history through secure APIs, and define clear rules on what the assistant could see and do.
Lesson. The model was never the problem. Data, integration and governance were. Once those were fixed, quality improved dramatically.
What These Cases Have in Common
- The hardest problems were rarely purely technical
- Gradual, well-sequenced change beat big-bang approaches
- Clear data ownership made everything easier
- Executive sponsorship mattered at key moments
- Reuse and governance paid off over time, not immediately
Final Thought
Every architecture case study is ultimately a story about trade-offs, people and timing. Learn to look for those, and every project you read about, or live through, becomes a lesson.