Dialogues on Software Architecture

Buy the Book

title: The Temple of Errors subtitle: A Socratic Dialogue on Debugging and Error Management in Software Architecture previous-chapter: url: chapter-14.html title: “Case Study: The Temple of Transactions”

0.1 Prologue: The Temple of Errors

The Agora of Code in Neo-Athens was alive with the hum of servers and the murmur of developers, but beneath the surface, a silent crisis brewed. Production errors—mysterious, elusive, and costly—plagued the city’s systems. Developers spent countless hours debugging, tracing, and guessing at the root causes of failures, while stakeholders grew increasingly frustrated with the downtime and lost productivity.

Under the shadow of the Debugging Willow—its branches swaying with error logs and its roots tangled in the city’s production systems—sat Simonos, the philosopher-architect, his tablet open to a blank canvas. Beside him, Typos, now a seasoned architect, paced like a detective on the trail of a culprit, his brow furrowed with the weight of unsolved mysteries.

“Simonos,” Typos began, his voice urgent, “the systems of Neo-Athens are drowning in errors. Every day, a new failure emerges—some trivial, some catastrophic. The developers are overwhelmed, and the stakeholders are losing faith. We need a way to detect, diagnose, and resolve these errors before they bring the city to its knees.”

Simonos set down his tablet and gestured to the empty space beside him. “Tell me, Typos: when a healer treats a patient, does he guess at the remedy, or does he first observe the symptoms, diagnose the ailment, and prescribe a cure?”

Typos stopped mid-stride. “He diagnoses and prescribes, of course. But debugging is not healing—it is a labyrinth of uncertainty, where the symptoms are often hidden or misleading.”

Simonos smiled. “Then let us build an Oracle of Debugging—an agentic AI that acts as a healer for our systems. It will observe the errors, diagnose their causes, and prescribe resolutions, just as a physician would for a patient.”

Typos sat, his mind alight with the challenge ahead. “Then where do we begin?”

Simonos leaned forward. “At the beginning, as always. Let us first understand the context and the stakeholders.”

1 Dialogue I: The Foundation – Context and Stakeholders

TYPOS: Simonos, the need is clear. But who are the stakeholders in this Oracle, and what do they truly need?

SIMONOS: Ah, Typos, the stakeholders are the voices that will shape this Oracle. Let us name them and their concerns:

  1. Developers:
    • Need: A system that quickly identifies the root cause of errors and suggests actionable fixes.
    • Concern: Accuracy. The Oracle must provide reliable diagnoses and practical solutions, not false leads.
  2. DevOps Engineers:
    • Need: A system that integrates seamlessly with their monitoring and logging tools (e.g., Prometheus, ELK, Datadog).
    • Concern: Observability. The Oracle must enrich their existing observability stack, not replace it.
  3. Product Owners:
    • Need: A system that reduces downtime and improves system reliability.
    • Concern: Business Impact. The Oracle must justify its cost by reducing mean time to resolution (MTTR).
  4. Security Officers:
    • Need: A system that respects data privacy and protects sensitive information (e.g., error logs containing PII).
    • Concern: Compliance. The Oracle must adhere to data protection regulations (e.g., GDPR, HIPAA).
  5. End Users:
    • Need: A system that minimizes disruptions to their experience.
    • Concern: Transparency. Users should not be negatively impacted by the Oracle’s operations.
  6. AI/ML Team:
    • Need: A system that learns and improves over time.
    • Concern: Maintainability. The Oracle’s models must be trainable, explainable, and updatable.

TYPOS: So the Oracle must serve many masters?

SIMONOS: Yes! And this is why we must begin with a system context diagram. Let us sketch it now.

1.1 The System Context Diagram

Simonos took up his stylus and drew on his tablet:

+---------------------+
|   Oracle of         |
|   Debugging         |
|                     |
+----------+----------+
           |
           | 1. Ingest Error Logs
           v
+----------+----------+
| Production Systems  |
+----------+----------+
           |
           | 2. Query for Diagnoses
           v
+----------+----------+
|   Developers        |
+----------+----------+
           |
           | 3. Fetch Observability Data
           v
+----------+----------+
| Monitoring Tools    |
| (Prometheus, ELK,    |
|  Datadog)           |
+----------+----------+
           |
           | 4. Validate Fixes
           v
+----------+----------+
|   DevOps Engineers   |
+---------------------+

SIMONOS: Here we see the boundaries of our Oracle and its external actors. The Oracle sits at the center, ingesting error logs from production systems, providing diagnoses to developers, fetching observability data from monitoring tools, and validating fixes with DevOps engineers.

TYPOS: And what of the quality attributes that shape this system?

SIMONOS: Let us define the architectural drivers—the quality attributes that will guide our design:

  1. Accuracy: The Oracle must provide correct diagnoses and actionable solutions with minimal false positives.
  2. Performance: The Oracle must analyze and diagnose errors in near real-time (under 5 seconds per error).
  3. Scalability: The Oracle must handle 10,000 concurrent error analyses during peak failure events.
  4. Security: The Oracle must protect sensitive data (e.g., PII in error logs) and prevent unauthorized access.
  5. Maintainability: The Oracle must be easy to update, retrain, and extend as new error patterns emerge.
  6. Explainability: The Oracle must provide transparent reasoning for its diagnoses to build trust with developers.
  7. Observability: The Oracle itself must be monitorable and debuggable.

2 Dialogue II: The Pillars – Architectural Patterns and Styles

TYPOS: Simonos, the requirements are clear. But what architectural style should we use for the Oracle? Should it be a monolith or a set of microservices?

SIMONOS: Ah, Typos, the choice of style must serve the Oracle’s goals and constraints. Let us consider the options:

  1. Microservices Style:
    • Pros:
      • Scalability: Each service (e.g., error ingestion, diagnosis, resolution) can scale independently.
      • Flexibility: Services can be updated or replaced without affecting the entire system.
      • Resilience: A failure in one service (e.g., diagnosis) does not bring down the entire Oracle.
    • Cons:
      • Complexity: Requires robust communication between services (e.g., via message queues or APIs).
      • Data Consistency: Harder to maintain consistency across distributed services.
  2. Event-Driven Style:
    • Pros:
      • Loose Coupling: Services communicate asynchronously via events (e.g., “Error Ingested”, “Diagnosis Complete”).
      • Resilience: Services can handle backpressure and failures gracefully.
    • Cons:
      • Complexity: Requires event sourcing or CQRS patterns to manage state.
      • Debugging: Harder to trace the flow of data across services.
  3. Serverless Style:
    • Pros:
      • Scalability: Automatically scales with the number of errors to analyze.
      • Cost-Effectiveness: Pay only for the compute resources used.
    • Cons:
      • Cold Starts: May introduce latency for infrequent error types.
      • Vendor Lock-In: Tightly coupled to a cloud provider’s serverless offerings.

TYPOS: Given the need for scalability, resilience, and real-time processing, it seems a microservices style with event-driven communication is the way to go.

SIMONOS: Indeed. And to structure the Oracle, we will use the C4 model: - Context View: We have already drawn this. - Container View: To show the high-level services and their interactions. - Component View: To detail the internal structure of each service. - Code View: To show the implementation details.

2.1 The Container View

Simonos drew again:

+---------------------+
|   Oracle of         |
|   Debugging         |
|                     |
|  +---------------+  |
|  |   API Gateway  |  <-- (NGINX/Kong)
|  +-------+--------+  |
|          |          |
|  +-------v--------+ |
|  | Error Ingestion| <-- (Kafka/Node.js)
|  |   Service      |  |
|  +-------+--------+ |
|          |          |
|  +-------v--------+ |
|  | Diagnosis      | <-- (Python/ML Models)
|  |   Engine       |  |
|  +-------+--------+ |
|          |          |
|  +-------v--------+ |
|  | Resolution     | <-- (Python/Rule Engine)
|  |   Suggester     |  |
|  +-------+--------+ |
|          |          |
|  +-------v--------+ |
|  | Knowledge Base  | <-- (PostgreSQL/Neo4j)
|  |   Service       |  |
|  +-------+--------+ |
|          |          |
|  +-------v--------+ |
|  | Observability  | <-- (Prometheus/Grafana)
|  |   Adapter       |  |
+---------------------+

SIMONOS: Here we see the containers—the high-level services that make up the Oracle:

  1. API Gateway:
    • Purpose: Routes requests from production systems and developers to the appropriate services.
    • Technology: NGINX or Kong.
  2. Error Ingestion Service:
    • Purpose: Collects and normalizes error logs from production systems.
    • Technology: Kafka for buffering, Node.js for processing.
  3. Diagnosis Engine:
    • Purpose: Analyzes error logs to identify root causes using machine learning models and rule-based matching.
    • Technology: Python with TensorFlow/PyTorch for ML, and a rule engine for deterministic diagnoses.
  4. Resolution Suggester:
    • Purpose: Generates actionable fixes based on diagnoses (e.g., code snippets, configuration changes, or rollback commands).
    • Technology: Python with a rule-based engine and templates for suggestions.
  5. Knowledge Base Service:
    • Purpose: Stores historical error patterns, diagnoses, and resolutions for reference and learning.
    • Technology: PostgreSQL for structured data, Neo4j for graph-based relationships (e.g., error patterns linked to root causes).
  6. Observability Adapter:
    • Purpose: Fetches additional context (e.g., metrics, traces) from monitoring tools to enrich error diagnoses.
    • Technology: Prometheus client for metrics, OpenTelemetry for traces.

TYPOS: How do these services communicate?

SIMONOS: They will communicate asynchronously using Kafka for event streaming. For example: - The Error Ingestion Service publishes an “Error Ingested” event to Kafka. - The Diagnosis Engine subscribes to this event, analyzes the error, and publishes a “Diagnosis Complete” event. - The Resolution Suggester subscribes to diagnoses and publishes a “Resolution Suggested” event. - The Knowledge Base Service and Observability Adapter provide additional context as needed.

3 Dialogue III: The Stones – Components, Interfaces, and Dependencies

TYPOS: Simonos, the containers are clear. But what of the components within each service? And how do we define their interfaces?

SIMONOS: Ah, Typos, let us dive deeper into the Diagnosis Engine, as it is the heart of our Oracle. Its components might include:

  1. Log Parser:
    • Responsibility: Extracts structured data (e.g., error type, timestamp, stack trace) from raw error logs.
    • Interface: parseLog(rawLog: str) -> StructuredError
  2. Pattern Matcher:
    • Responsibility: Matches error patterns against a database of known issues (e.g., “NullPointerException in Module X”).
    • Interface: matchPattern(error: StructuredError) -> List[KnownIssue]
  3. ML Classifier:
    • Responsibility: Uses a supervised machine learning model to classify errors into categories (e.g., “database timeout”, “memory leak”).
    • Interface: classifyError(error: StructuredError) -> ErrorCategory
  4. Context Enricher:
    • Responsibility: Augments error data with observability context (e.g., CPU usage, recent deployments) from the Observability Adapter.
    • Interface: enrichContext(error: StructuredError) -> EnrichedError
  5. Diagnosis Generator:
    • Responsibility: Combines the outputs of the Pattern Matcher and ML Classifier to generate a final diagnosis.
    • Interface: generateDiagnosis(enrichedError: EnrichedError) -> Diagnosis

TYPOS: And what of dependencies between these components?

SIMONOS: Dependencies must be managed carefully to avoid tight coupling. Here’s how we will handle them:

  1. Dependency Injection:
    • Components will depend on abstractions, not concrete implementations. For example, the Diagnosis Generator will depend on a Classifier interface, not the ML Classifier directly.
  2. Event-Driven Communication:
    • Components will communicate via internal events (e.g., “Pattern Matched”, “Classification Complete”) published to an in-memory event bus.
  3. Circuit Breakers:
    • If the Observability Adapter is down, the Context Enricher will use a fallback context (e.g., cached metrics) and log a warning.

TYPOS: So the components are cohesive and loosely coupled?

SIMONOS: Precisely! This ensures that each component can be modified, replaced, or scaled independently.

4 Dialogue IV: The Mortar – Cross-Cutting Concerns

TYPOS: Simonos, the components and services are well-defined. But what of cross-cutting concerns like security, logging, and explainability?

SIMONOS: Ah, Typos, these are the mortar that binds the Oracle together. Let us address them one by one:

  1. Security:
    • Tactics:
      • Data Redaction: Strip PII (e.g., user IDs, IP addresses) from error logs before processing.
      • Authentication/Authorization: Use OAuth2 and RBAC to control access to the Oracle’s APIs and data.
      • Encryption: Encrypt data in transit (TLS) and at rest (AES-256).
      • Audit Logging: Log all access to the Oracle for compliance and debugging.
  2. Logging:
    • Tactics:
      • Use a centralized logging service (e.g., ELK Stack) to aggregate logs from all services.
      • Include correlation IDs to trace requests across services.
      • Log structured data (JSON) for easier analysis.
  3. Explainability:
    • Tactics:
      • For rule-based diagnoses, include the matched rule and input data in the output.
      • For ML-based diagnoses, use SHAP (SHapley Additive exPlanations) or LIME (Local Interpretable Model-agnostic Explanations) to explain the model’s reasoning.
      • Provide a confidence score for each diagnosis (e.g., “95% confidence this is a database timeout”).
  4. Observability:
    • Tactics:
      • Use Prometheus and Grafana to monitor system metrics (e.g., error analysis latency, diagnosis accuracy).
      • Set up alerts for abnormal behavior (e.g., high error rates, low confidence scores).
      • Use distributed tracing (e.g., Jaeger) to track requests across services.
  5. Performance:
    • Tactics:
      • Caching: Cache frequent error patterns and diagnoses in Redis.
      • Batch Processing: Process errors in batches where real-time analysis is not required.
      • Load Balancing: Distribute requests across multiple instances of the Diagnosis Engine.

TYPOS: So these concerns are centralized and managed across the system?

SIMONOS: Yes! They are the invisible threads that ensure the Oracle is secure, transparent, and resilient.

5 Dialogue V: The Data – Architecture of Knowledge

TYPOS: Simonos, the services and cross-cutting concerns are clear. But what of the data architecture? How will we store and manage the Oracle’s knowledge?

SIMONOS: Ah, Typos, the data architecture is the knowledge of our Oracle. Let us design it with care. The system will have three primary data stores:

  1. PostgreSQL (Relational Database):
    • Purpose: Store structured data such as:
      • Errors: Raw error logs, timestamps, and metadata.
      • KnownIssues: Database of known error patterns, root causes, and resolutions.
      • Diagnoses: Historical diagnoses and their accuracy scores.
    • Why: ACID compliance ensures consistency for critical data.
  2. Neo4j (Graph Database):
    • Purpose: Store relationships between errors, root causes, and resolutions (e.g., “Error X is caused by Y, which is fixed by Z”).
    • Why: Graph databases excel at traversing relationships, which is critical for linking errors to their root causes.
  3. Redis (Cache):
    • Purpose: Cache frequent error patterns and diagnoses to improve performance.
    • Why: Low-latency access reduces the load on PostgreSQL and Neo4j.
  4. Elasticsearch (Search Engine):
    • Purpose: Enable full-text search across error logs and diagnoses (e.g., “Find all errors related to database timeouts”).
    • Why: Elasticsearch excels at text-based queries and aggregations.

TYPOS: And what of data consistency? How will we ensure the Oracle’s knowledge remains accurate?

SIMONOS: We will use a combination of ACID transactions for critical operations (e.g., updating the KnownIssues database) and eventual consistency for less critical data (e.g., caching in Redis). For example: - When a new error is ingested, the Error Ingestion Service will: 1. Store the raw error in PostgreSQL (ACID transaction). 2. Publish an “Error Ingested” event to Kafka. 3. The Diagnosis Engine will process the error and update the Neo4j graph with new relationships (eventual consistency). 4. The Resolution Suggester will cache frequent diagnoses in Redis.

TYPOS: So the data architecture is designed for performance and relationships?

SIMONOS: Yes! It is the foundation on which the Oracle’s wisdom is built.

6 Dialogue VI: The Brain – Machine Learning and Knowledge

TYPOS: Simonos, the data architecture is clear. But how does the Oracle learn and improve over time?

SIMONOS: Ah, Typos, the Oracle’s intelligence is its greatest asset. It must learn from every error it encounters. Let us explore how:

  1. Supervised Learning:
    • Purpose: Train models to classify errors into categories (e.g., “database timeout”, “memory leak”).
    • Process:
      • Training Data: Historical error logs labeled with their root causes by developers.
      • Model: A classification model (e.g., Random Forest, Neural Network) trained on this data.
      • Inference: The model classifies new errors based on their features (e.g., error message, stack trace, context).
  2. Unsupervised Learning:
    • Purpose: Discover new error patterns that have not been seen before.
    • Process:
      • Clustering: Use k-means or DBSCAN to group similar errors.
      • Anomaly Detection: Use Isolation Forest or Autoencoders to identify outliers (e.g., novel errors).
  3. Reinforcement Learning:
    • Purpose: Improve the Oracle’s resolution suggestions based on feedback from developers.
    • Process:
      • Feedback Loop: Developers rate the Oracle’s diagnoses and resolutions (e.g., “Was this suggestion helpful?”).
      • Reward Signal: The Oracle adjusts its models to prioritize suggestions that receive high ratings.
  4. Rule-Based System:
    • Purpose: Provide deterministic diagnoses for known error patterns.
    • Process:
      • Rules Engine: A set of if-then rules (e.g., “IF error contains ‘NullPointerException’ AND stack trace includes ‘Module X’, THEN diagnose as ‘Uninitialized Object in Module X’”).
      • Maintenance: Rules are updated as new patterns emerge.

TYPOS: So the Oracle combines machine learning and rule-based systems?

SIMONOS: Yes! This hybrid approach ensures that the Oracle is both adaptive (via ML) and reliable (via rules). For example: - A new error might first be classified by the ML model. - If the confidence is low, the rule-based system can provide a fallback diagnosis. - Over time, the ML model learns from the rule-based system’s successes and failures.

7 Dialogue VII: The Trials – Evaluation and Risks

TYPOS: Simonos, the architecture seems sound. But how do we evaluate it to ensure it meets the Oracle’s goals?

SIMONOS: Ah, Typos, evaluation is the trial by fire that tempers our design. Let us use the ATAM (Architecture Tradeoff Analysis Method) to assess our architecture:

7.1 Step 1: Present the Architecture

We will present the container view, component view, and data architecture to stakeholders.

7.2 Step 2: Define Quality Attribute Scenarios

Let us define some scenarios to test the architecture:

  1. Accuracy Scenario:
    • Stimulus: An error with a known root cause (e.g., database timeout) is ingested.
    • Response: The Oracle correctly diagnoses the error and suggests the correct resolution (e.g., “Increase database connection pool size”).
    • Measure: Diagnosis accuracy rate (target: >95%).
  2. Performance Scenario:
    • Stimulus: 10,000 concurrent errors are ingested.
    • Response: The Oracle processes all errors in under 5 seconds.
    • Measure: Latency and throughput.
  3. Security Scenario:
    • Stimulus: An error log containing PII (e.g., user email) is ingested.
    • Response: The Oracle redacts the PII before processing and stores it securely.
    • Measure: Compliance audit (target: 100% redaction).
  4. Explainability Scenario:
    • Stimulus: A developer requests an explanation for a diagnosis.
    • Response: The Oracle provides a clear, understandable reason (e.g., “This error matches Pattern X, which is caused by Y. Confidence: 90%”).
    • Measure: Developer satisfaction score (target: >4/5).

7.3 Step 3: Analyze Risks

Let us identify risks and their mitigation strategies:

Risk Likelihood Impact Mitigation Strategy
False Positives Medium High Use hybrid ML + rule-based diagnoses.
Performance Bottleneck Medium High Use caching (Redis) and batch processing.
Data Privacy Violation Low Critical Implement automated PII redaction.
Model Drift High Medium Retrain models regularly with new data.
Integration Failures Medium High Use circuit breakers and fallback mechanisms.
Explainability Issues Medium Medium Use SHAP/LIME for ML explanations.

TYPOS: So evaluation helps us uncover risks before they become catastrophes?

SIMONOS: Yes! It is the difference between an Oracle that guides and an Oracle that misleads.

8 Dialogue VIII: The Debt – Technical and Architectural

TYPOS: Simonos, the architecture seems robust. But what of technical debt? How do we ensure it does not accumulate?

SIMONOS: Ah, Typos, technical debt is the shadow that follows every system. Let us identify potential debts in our architecture and how we will manage them:

Debt Cause Impact Mitigation Strategy
Tight Coupling Services depend directly on each other. Hard to modify or scale services. Use interfaces and asynchronous communication.
Lack of Documentation No ADRs or architecture diagrams. Hard for new developers to onboard. Document all decisions in ADRs.
Poor Model Explainability ML models are “black boxes”. Developers distrust diagnoses. Use SHAP/LIME and rule-based fallbacks.
Hardcoded Rules Rules are not externalized. Hard to update rules dynamically. Store rules in a database or config file.
Data Silos Data is scattered across stores. Hard to correlate and analyze. Use a data mesh or unified query layer.
Lack of Monitoring No observability for the Oracle. Hard to debug and improve. Implement Prometheus + Grafana.

TYPOS: So technical debt is inevitable, but manageable?

SIMONOS: Yes! The key is to acknowledge it, prioritize it, and address it incrementally.

9 Dialogue IX: The Scrolls – Documenting and Communicating

TYPOS: Simonos, the architecture is clear. But how do we document it so that others can understand and maintain the Oracle?

SIMONOS: Ah, Typos, documentation is the scrolls that preserve the Oracle’s wisdom. Let us define the key artifacts:

  1. Architecture Decision Records (ADRs):
    • Purpose: Document why decisions were made (e.g., “Why Kafka for event streaming?”).
    • Format: Markdown files in a /docs/adr directory.
    • Example ADR:
      • Title: Use Kafka for Event Streaming
      • Status: Accepted
      • Context: Need a scalable, fault-tolerant way to handle high-volume error events.
      • Decision: Use Apache Kafka.
      • Consequences: High throughput, but adds operational complexity.
  2. System Context Diagram:
    • Purpose: Show the boundaries and external interactions of the Oracle.
  3. Container and Component Diagrams:
    • Purpose: Visualize the structure of the Oracle using the C4 model.
  4. Data Architecture Diagram:
    • Purpose: Show how data flows between PostgreSQL, Neo4j, Redis, and Elasticsearch.
  5. API Documentation:
    • Purpose: Describe the interfaces of each service (e.g., using OpenAPI/Swagger).
  6. Machine Learning Model Cards:
    • Purpose: Document the training data, performance metrics, and limitations of each ML model.
    • Example:
      • Model Name: Error Classifier v1.0
      • Training Data: 10,000 labeled error logs.
      • Accuracy: 92%
      • Limitations: Struggles with novel error types.
  7. Operational Guides:
    • Purpose: Explain how to deploy, monitor, and maintain the Oracle.

TYPOS: So documentation ensures the Oracle’s legacy endures?

SIMONOS: Yes! It is the memory of the Oracle, ensuring that future architects understand its design, decisions, and purpose.

10 Dialogue X: The Launch – Deployment and Beyond

TYPOS: Simonos, the architecture is ready. But how do we deploy the Oracle and ensure it thrives?

SIMONOS: Ah, Typos, deployment is not the end, but the beginning of the Oracle’s life. Let us define the deployment strategy:

10.1 Phase 1: Pilot

10.2 Phase 2: Expansion

10.3 Phase 3: Full Deployment

TYPOS: So deployment is the start of the journey?

SIMONOS: Yes! The Oracle is never finished—it is only ready for its first acolyte.

11 Epilogue: The Oracle Awakens

Typos stood, his mind alight with the realization that the Oracle of Debugging was not just a tool, but a living entity—shaped by the needs of its users, tempered by the fires of evaluation, and preserved by the scrolls of documentation.

“Simonos,” he said, “I feel as though we have not just designed a system, but crafted a guardian. This Oracle will serve Neo-Athens as a beacon of clarity in the storm of errors.”

Simonos nodded, his eyes reflecting the glow of the Debugging Willow. “Indeed, Typos. The architect is not just a builder, but a healer. We have not just designed an Oracle—we have forged a covenant between the city and its systems, ensuring that every error is met with wisdom, every failure with resolution.”

Typos turned to the whiteboard, where the outlines of the Oracle of Debugging stood complete—a system evaluated, protected, and ready to learn.

“Then let us present this to the developers of Neo-Athens,” he said.

Simonos smiled. “With wisdom as our guide, and clarity as our light.”

11.1 Key Themes and Takeaways

This case study demonstrates how the principles and practices of software architecture come together to solve a real-world problem—building an agentic AI to debug production errors. Here’s how each aspect of the previous chapters was applied:

11.2 1. Stakeholders and Requirements (Ch. 2)

11.3 2. Architectural Patterns and Styles (Ch. 6)

11.4 3. Components, Interfaces, and Dependencies (Ch. 7)

11.5 4. Cross-Cutting Concerns (Ch. 8)

11.6 5. Data and Information Architecture (Ch. 9)

11.7 6. Architecture Views and Methods (Ch. 10)

11.8 7. Documenting and Communicating Architectures (Ch. 11)

11.9 8. Quality Attributes and Tactics (Ch. 12)

11.10 9. Evaluation, Risks, and Technical Debt (Ch. 13)