Core Idea

The Architecture Style Selection Framework is a systematic six-step process for choosing an architecture style based on characteristics, business drivers, and trade-off analysis rather than trends or personal preferences.

What Is the Architecture Style Selection Framework?

Purpose: The Architecture Style Selection Framework provides a disciplined approach to one of architecture’s most critical decisions: which architectural style to adopt:

  • Instead of following trends (microservices are popular!)
  • Or defaulting to familiar patterns (we always use layered architecture)
  • This framework forces explicit analysis of business requirements translated into architectural characteristics

Six Sequential Steps:

  1. Identify architecture characteristics: Use the extraction process from Chapter 5

    • Both explicit characteristics stated by stakeholders
    • And implicit characteristics inherent to the domain
  2. Rank characteristics by priority:

    • Priority 1: Must-haves
    • Priority 2: Important
    • Priority 3: Nice-to-have
  3. Evaluate candidate styles: Assess each candidate architecture style’s support for your top characteristics using the ratings provided in the style chapters

  4. Identify best-fit styles: Typically two or three candidates that excel at your highest-priority characteristics

  5. Analyze trade-offs: Examine what you sacrifice in lower-priority characteristics for each candidate

  6. Choose the style: Select the style that offers the best overall trade-off profile for your specific priorities

Power of Systematic Approach: What makes this framework powerful is its systematic nature:

  • Prevents “architecture by committee”: Where decisions emerge from political compromise rather than technical analysis
  • Prevents “architecture by resume-building”: Where architects choose styles to pad their CVs rather than serve business needs

Context-Dependent: The framework acknowledges that no style is universally superior:

  • Example 1: A layered architecture might be perfect for a simple CRUD application where rapid time-to-market matters most
  • Example 2: The same style would be catastrophic for a high-volume, real-time trading platform that requires extreme performance and scalability
  • Key insight: The “best” architecture is always context-dependent

Why This Matters

Architecture style selection has profound long-term consequences. Once a system is built in a particular style, migrating to a different style requires significant investment. Making this decision based on systematic analysis of business drivers rather than trends or familiarity dramatically increases the probability of long-term success.

The framework also creates a defensible decision. When stakeholders question why you chose microservices over a monolith (or vice versa), you can point to explicit characteristic rankings and trade-off analysis rather than subjective preferences.

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.