Image "avalski-toranj-2-1-640x1138.jpg" by urbancitystudio.org is licensed under CC BY-SA 4.0. This work has been cropped and filtered from the original.
Image "Belgrade_Waterfront_2_(cropped).jpg" by Kallerna is licensed under CC BY-SA 4.0. This work has been cropped and filtered from the original.

Solution Design Frameworks & Models

While TOGAF provides the overarching enterprise structure, specific solution designs require tactical frameworks to ensure technical excellence, scalability, and agility.

1. AWS Well-Architected Framework

This framework provides a consistent set of strategies and best practices for designing and evaluating cloud architectures. It moves away from heavy documentation and focuses on 6 Pillars:

  • Operational Excellence: Running and monitoring systems.
  • Security: Protecting information and assets.
  • Reliability: Ensuring workloads perform their intended functions.
  • Performance Efficiency: Using computing resources efficiently.
  • Cost Optimization: Avoiding unnecessary costs.
  • Sustainability: Minimizing the environmental impact.

Why it suits Solution Design: It provides concrete checklists and "Lenses" that help architects validate if their specific solution is production-ready.

2. Azure Well-Architected Framework

Similar to the AWS version, this WAF framework is a set of guiding tenets used to improve the quality of a workload. It focuses on 5 Pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.

Why it suits Solution Design: It is deeply integrated with the Azure Advisor and Assessment tools, allowing architects to get real-time, automated feedback on their solution design.

3. C4 Model (Context, Containers, Components, Code)

Created by Simon Brown, the C4 model is a lean graphical notation technique for modeling software architecture through hierarchical diagrams:

  • Level 1 (Context): Shows the big picture and how users/other systems interact with the solution.
  • Level 2 (Containers): Shows high-level technical choices (e.g., Web App, Database, Mobile App).
  • Level 3 (Components): Breaks down containers into internal components.
  • Level 4 (Code): Optional deep dive into class diagrams.

Why it suits Solution Design: It eliminates "wall of text" documentation by allowing architects to explain a solution to different stakeholders by simply "zooming" in or out.

4. Poka-Yoke

Poka-Yoke is a methodology within Lean Manufacturing focused on preventing human errors in processes or making them immediately detectable before they result in defects. The concept assumes that mistakes are inevitable, but systems can be designed to either eliminate the possibility of error or quickly identify it. The ultimate objective is to achieve near-zero defects without relying on end-of-line inspection, by embedding quality directly into the process.

  • Prevention (Control): Design systems that physically or logically make errors impossible (e.g., components that fit only one way).
  • Detection (Warning): Allow errors but ensure they are instantly identified and signaled (e.g., alarms or system prompts).
  • Simplicity: Solutions should be low-cost, intuitive, and easy to implement.
  • Immediate feedback: Errors must be detected at the source, not later in the process.
  • Standardization: Once implemented, solutions should be consistently applied across the process.

Poka-Yoke methods typically include contact methods (detecting deviations in shape, size, or color), fixed-value methods (ensuring a specific number of actions are completed), and motion-step methods (enforcing correct process sequence). These techniques are widely used in manufacturing industries such as automotive and electronics, as well as in logistics, supply chain operations, and software systems (e.g., input validation, workflow enforcement). They are also embedded in everyday products to enhance safety and usability.

In terms of solution architecture Poka-Yoke manifests as design patterns and guardrails, and scalable digital workflows with built-in error-proofing, manifested as discrete design principles (example).

6. IASA (International Association of Software Architects)

The IASA model (found in the BTABoK — Business Technology Architecture Body of Knowledge) is a value-driven engagement framework rather than a rigid step-by-step process. While frameworks like TOGAF focus on "how to document the enterprise," IASA focuses on "how the architect delivers value."

IASA organizes architecture around five core competencies:

  • Business Technology Strategy: Aligning tech with business value.
  • Design: Mastery of patterns, styles, and modeling.
  • Human Dynamics: Leadership, stakeholder management, and psychology.
  • Quality Attributes: Managing the "ilities" (scalability, security, etc.).
  • IT Environment: Understanding the technical landscape (platforms/governance).

The Engagement Model: This is the "active" part of the methodology. It defines how architects interact with stakeholders throughout the product lifecycle. It emphasizes Continuous Architecture—integrating design decisions directly into Agile/DevOps loops rather than waiting for a formal "architecture phase."

Structured Canvases: To keep it "lightweight," IASA uses visual tools (like the Architecture Decision Record or Value Management canvases) to capture critical information quickly on a single page, replacing hundreds of pages of traditional documentation.

6. Agile Architecture

In an Agile context, architecture is built incrementally. It focuses on the Architectural Runway, the technical foundation that enables business features to be implemented quickly.

  • Emergent Design: Technical details evolve as the team learns more.
  • Intentional Architecture: High-level guidance that keeps the team aligned.

Why it suits Solution Design: It avoids "Big Design Up Front" (BDUF), ensuring the architecture remains flexible as business requirements change.